add log tailing to logfetch tool #383
Conversation
| @@ -70,7 +74,8 @@ def entrypoint(): | |||
| parser.add_argument("-u", "--singularity-uri-base", help="The base for singularity (eg. http://localhost:8080/singularity/v1)", metavar="URI") | |||
| parser.add_argument("-s", "--start-days", help="Search for logs no older than this many days", type=int, metavar="start_days") | |||
| parser.add_argument("-e", "--end-days", help="Search for logs no new than this many days (defaults to None/today)", type=int, metavar="end_days") | |||
| parser.add_argument("-g", "--grep", help="Regex to grep for (normal grep syntax) or a full grep command", metavar='grep') | |||
| parser.add_argument("-g", "--grep", help="Regex to grep for (normal grep syntax) or a full grep command(cannot use full command with --tail)", metavar='grep') | |||
| parser.add_argument("--tail", help="Logfile name to tail, if this is set, no downloads will happen", metavar="tail") | |||
There was a problem hiding this comment.
can we mimic the tail command and use -t as well (make people think less)?
|
what happens then a request churns through tasks (i.e. OOM kill / misc. failure / bounce / deploy)? right now we won't pick up new tasks -- if we're cool with that, we need to make it very clear in the docs |
|
i'd almost prefer to have a 2nd entrypoint ( |
|
I've made logtail it's own entrypoint and reworked the threading a bit, we were using -t for the taskId already so for right now I made -l the logfile name to tail |
| parser.add_argument("-d", "--deployId", help="DeployId of task to fetch logs for", metavar="deployId") | ||
| parser.add_argument("-u", "--singularity-uri-base", help="The base for singularity (eg. http://localhost:8080/singularity/v1)", metavar="URI") | ||
| parser.add_argument("-s", "--start-days", help="Search for logs no older than this many days", type=int, metavar="start_days") | ||
| parser.add_argument("-e", "--end-days", help="Search for logs no new than this many days (defaults to None/today)", type=int, metavar="end_days") |
There was a problem hiding this comment.
start and end is unnecessary for tail, right?
There was a problem hiding this comment.
it was previously used for filtering our really old historical tasks, realizing we won't need those for tailing live logs, I'll remove those and the piece that fetches historical tasks as well
|
re: #383 (comment) -- totally overlooked |
|
Tailing should be all set now, I've trimmed the arguments down to just the IDs, logfile, and grep string (along with the base uri/conf file stuff). I left the logfile arg as giving an error message if it is not set. |
@tpetr @wsorenson
This will add the ability to tail logs for a request, task, or request/deploy when the --tail option is specified with a logfile path (ie. 'logs/access.log'). It will also take the -g grep option and pas that through to the api as well.
If --tail isn't specified the tool will download and grep as before.