Detect if reporter shuts down?

[PizzaBrandon]

I'm using good-loggly to report directly from my instance to Loggly. Often I'll check my dashboard and notice nothing is being sent and a restart of my instance fixes it. I assume the reporter is being shut down when one of my attempts to communicate with Loggly fails (likely due to a spotty NAT).

I thought I remembered there being a way to detect when a reporter shuts down so the application can take an appropriate action, but I cannot find anything outside of the console.error call. I will likely have to change my logging strategy for the local log file to be piped to Loggly, but I was hoping I could address this directly in my code.

Is (or was) there anything like this that I'm missing?

For reference, here is the registration object I'm using in my glue manifest:

const goodReporters = {
  console: [{
    module: 'good-squeeze',
    name: 'Squeeze',
    args: [{
      response: '*',
      error: '*',
      request: [ 'metrics', 'security', 'error', 'log' ],
      log: '*'
    }]
  }, {
    module: 'good-console'
  }, 'stdout' ],

  loggly: [{
    module: 'good-squeeze',
    name: 'Squeeze',
    args: [{
      response: '*',
      error: '*',
      request: [ 'metrics', 'security', 'error', 'log' ],
      log: '*'
    }]
  }, {
    module: 'good-loggly',
    args: [{
      token: process.env.LOGGLY_TOKEN,
      subdomain: process.env.LOGGLY_SUBDOMAIN,
      tags: process.env.LOGGLY_TAGS ? process.env.LOGGLY_TAGS.split(',') : null,
      name: process.env.LOGGLY_NAME,
      hostname: process.env.LOGGLY_HOSTNAME || Os.hostname(),
      threshold: parseInt(process.env.LOGGLY_THRESHOLD, 10) || 0,
      maxDelay: parseInt(process.env.LOGGLY_MAX_DELAY, 10) || 0
    }]
  }]
};

[arb]

No. There isn't really anything like that directly in good. That's something that would need to be implemented on a per-stream basis. good-http has a concept of a "retry" if you're looking for something like that.

[PizzaBrandon]

If a worthwhile concept for a way for an application to check good's status was proposed, would you consider a PR?

[PizzaBrandon]

Although, I see exposing monitor was taken away in 532bc88. Could something like this be re-added to expose the status of the reporters?

[arb]

What would you want regarding status? I really don't want to expose the whole monitor object again as it quickly turned into a maintenance issue because the API surface was huge because of it.

[PizzaBrandon]

I'm not sure at the moment; I will have to dig in deeper. I was only pointing that out as that's in the vein of what I would have proposed.

I'll have to think further. The only action the program can take right now is terminating itself so it can be restarted - which is terribly extreme. I don't see a quick solution for a way of sanely restarting (technically re-creating) a terminated stream.

[PizzaBrandon]

I don't have a good answer for you so I'm going to close this issue.

Maybe, instead of monitor, expose a function to query the list of active reporters. If an expected reporter is missing, the application owner can take their desired action. Alternatively (or in conjunction), emit an event so the application doesn't have to query regularly for the status.

I'm going to investigate other more reliable ways of collecting and publishing my logs instead of attempting to communicate directly with the service. This will allow me to plug a hole that's been nagging me for my security group configuration.

[lock[bot]]

This thread has been automatically locked due to inactivity. Please open a new issue for related bugs or questions following the new issue template instructions.