daniellavoie commented on issue #6524:
URL:
https://github.com/apache/incubator-pinot/issues/6524#issuecomment-774816316
> hmm, in this case, shall we actually provide an API `/logs` in each pinot
component to fetch the log file?
This will not solve the problem I'm trying to frame. First of all, a `/logs`
endpoint will expose everything and still only means something to an operator.
My persona is not an SRE but an actual data administrator. To some extend, it
could even be a webapp that manages table configs on top of Pinot. If each
table maintains state of their ingestion status and any error report (e.g.: the
kafka bootstrap server is unavailable), this will greatly improve the ability
of pinot users (again not SRE) to self troubleshoot configuration errors or
even table troubleshoot temporary errors (Kafka not available). Different
tables may face different ingestion status, and error root cause. One table may
have an S3 credential error while the second is failing to communicate with
Kafka. This status could actually be a nested `status` field within
`/table/{tableName}` output. Or even maybe a
`/table/{tableName}/ingestion-status` endpoint.
My last comment regarding a log file approach: exposing a `/logs` endpoint
is not very possible since logs are independently configured with log4j, the
app is not really aware where the logs are actually spitted. Keep in mind that
best practices instruct to output logs to stdout and not a specific log file.
Anyways, the log approach should not be considered.
cc @kishoreg
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@pinot.apache.org
For additional commands, e-mail: commits-h...@pinot.apache.org
