cronitorio / cronitor-kubernetes Goto Github PK

Would it be possible to support helm charts on arm64 architecture? Thanks.

Hello, I tried to install the helm chart of Cronitor following the docs, however the POD keeps restarting due this error:

time="2022-10-20T14:57:13Z" level=info msg="Enabling Sentry instrumentation..."
time="2022-10-20T14:57:13Z" level=info msg="no kubeconfig provided, defaulting to in-cluster..."
Error: the server could not find the requested resource
Usage:
  cronitor-kubernetes agent [flags]

Flags:
      --dryrun             Dry run, do not actually send updates to Cronitor
  -h, --help               help for agent
      --namespace string   Scope agent collection to only a single Kubernetes namespace
      --ship-logs          Collect and archive the logs from each CronJob run upon completion or failure

Global Flags:
      --apikey string       Cronitor.io API key
      --kubeconfig string   path to a kubeconfig to use
      --log-level string    Minimum log level to print for the agent (TRACE, DEBUG, INFO, WARN, ERROR)

Request for New Feature：

We need to customize the timing of sending the "complete" signal because we will combine the queue for asynchronous task processing. Therefore, the completion of a cronjob does not signify the end of the entire task execution. The "complete" ping should be sent by the program after all tasks in the queue have been fully processed.

• Disable the cronitor telemetry ping from cronitor-kubernetes.

Recommend

Is it possible to turn off cronitor-kubernetes telemetry pings and send telemetry entirely by the users themselves.

Can we define a new annotation similar to "k8s.cronitor.io/disable-complete"? If this is set to true, the sending of the complete signal should be ignored.

Using groups is currently pretty awkward for k8s job deployments. We like them, but the assigning the group is a manual process that has to be done post job creation.

I'd propose adding a new annotation so that the cronitor-agent can automatically assign the monitor for a job to a particular group:

k8s.cronitor.io/cronitor-group: "foo-jobs"

This would allow us to specify the monitor group at deployment time, which would simplify our lives quite a bit

Kubernetes 1.25 appears to have had some API deprecations, resulting in the agent failing to start. Surfaced in #18.

Request:
The cronitor-kubernetes can automatically create and update job monitors from CronJob, but the controller does not automatically delete the Job-Monitoring when CronJob are deleted.

Idea:
Can a new annotation be added? Users can choose Job-monitoring, which has the same life cycle as cronjobs.

Capturing a conversation with @aflanagan!

Naming things is hard... but we think that the default naming right now isn't practical when combined with Jobs across environments. My expectation is that a CronJob that's picked up in multiple environments with an identical name should have the same key within Cronitor.

There are a couple things working against us here:

• The key is being set to the Kubernetes object UID, which will implicitly be unique between environments.
• If the namespace has the environment baked into the name, then the name within Cronitor Job will reflect this.

Proposed solutions, relying on annotations to keep things flexible:

• k8s.cronitor.io/id-inference: String
  • k8s
    • current behavior
  • name
    • hashes the name of the job
• k8s.cronitor.io/name-prefix: String
  • namespace
    • current behavior
  • none
    • no prefix
  • anything else (this seems like a nice to have)
    • prepend to name

Hi Team,

The agent works great but I was wondering if we could enhance the formatter to spit out json instead of txt or the loglevel via variables in the values file.

Thank you!

Hi! Could you please add some license to the repo so community could know how and if code can be reused?

I'd propose adding a new annotation so that the cronitor-agent can automatically assign the note for a job:

k8s.cronitor.io/cronitor-note: "This is my job"

This would allow us to specify the monitor note at deployment time, which would simplify our lives quite a bit.