InfluxDB bucket retention

[mpass99]

No description provided.

[mpass99]

@MrSerth What would be a suitable retention?

• The telegraf-bucket already has a retention of 30 days.
• For the poseidon-bucket it depends
  • General Information
    • poseidon_/execute, poseidon_/execution-environments, poseidon_/files, poseidon_/files/raw, poseidon_/files_list, poseidon_/health, poseidon_/version, poseidon_/websocket, poseidon_createOrUpdate, poseidon_deleteRunner, poseidon_environments, poseidon_file_download, poseidon_list, poseidon_aws_executions, poseidon_nomad_executions, poseidon_nomad_idle_runners, poseidon_poolsize, poseidon_provideRunner, poseidon_used_runners
  • Debug Information
    • poseidon_nomad_allocations, poseidon_nomad_events

While the general information might be interesting for future analysis, the debug information likely is not and probably takes up the most disk space. We might set up an Influx Task to regularly delete those data points older than something (30d).

[MrSerth]

Ah, thanks for making this overview here -- I like that.

• In general, I agree with your (proposed) retention policies: Having the Telegraf and Poseidon debug information ready for something like 30days is nice; for the debugging, we could actually decide to extend that a little (to two months?) since we would have had some issues in assessing the Sentry issues otherwise.
• For implementing the retention, I though of using a retention policy rather than an Influx Task -- where do you see the advantage?
• Are we sure that we don't need any old data for resolving remaining Sentry issues? I just want to ensure that we don't delete necessary debug information for old issues without any recent activity.
• Can we persist this overview (with the upcoming changes) somewhere (e.g., in the codeocean-terraform repo), so that we don't loose that?

[mpass99]

I though of using a retention policy rather than an Influx Task -- where do you see the advantage?

Judging by my superficial understanding, retention policies allow us to delete the data of the whole bucket, but not to specify just one or two measurements to be deleted.

Are we sure that we don't need any old data for resolving remaining Sentry issues?

That's a fair point and proved to be useful in recent history. Now, however, might be a good point in time to implement the bucket retention. We resolved many bugs and Sentry issues and had many corresponding changes that might render old data unuseful, anyway.