prometheus:
command: '--config.file=/etc/prometheus.yml --storage.tsdb.retention.time=2h'
container_name: remi_prometheus
depends_on:
- cadvisor
expose:
- '9090'
image: prom/prometheus:latest
labels:
project.run.user: remi
networks:
project-bridge:
aliases:
- prometheus
ports:
- published: 9090
target: 9090
volumes:
- remi-prometheus:/prometheus:rw
- /home/remi/Workspace/project/runtime/configuration/prometheus.yml:/etc/prometheus.yml:rw
version: '3.4'
scrape_configs:- job_name: cadvisor scrape_interval: 5s static_configs: - targets: - localhost:8080
> an email to promethe...@googlegroups.com
> <mailto:prometheus-users+unsub...@googlegroups.com>.
Hi,
Thanks for the answer.
Just to add some context to what I want to do. We are trying to make our application (Prometheus being a part of it) compliant with GDPR. The default period for our data retention is 10 days but can be set by the user to 1h minimum. If the data are not deleted after 1 hour then, it is no longer compliant with what we declared to the national data protection authority.
From your answer, I understand now that the parameter storage.tsdb.retention.time is not hard deadline for the data. Data might live after the retention time, at least 2 hours. So I launched a new test with storage.tsdb.retention.time equals to 5m. Then, I waited for 3 hours to see if the data were deleted but they are always in Prometheus.
Is it possible to anticipate when the data will be deleted to update ours compliance with GDPR? Can we change the background schedule to have a better estimation of when the data will be deleted? Or should I use the delete method of Prometheus form an external component to be sure that the data are deleted on time?
What data are you expecting Prometheus to hold that would be subject to GDPR?
Prometheus stores monitoring metrics so wouldn't have anything
related to personal data, so isn't in scope for GDPR...
To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-users/27f3c76c-f2b3-4bfe-87d7-02adbf61f8c4%40googlegroups.com.
-- Stuart Clark
Thanks,
Best regards.
> <mailto:prometheus-use...@googlegroups.com>.
--
You received this message because you are subscribed to the Google Groups "Prometheus Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-users/27f3c76c-f2b3-4bfe-87d7-02adbf61f8c4%40googlegroups.com.
-- Stuart Clark
--
You received this message because you are subscribed to the Google Groups "Prometheus Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-users/e056715f-cf27-5e5d-743f-686c835c8207%40Jahingo.com.
Yes, this is the general guideline. User identifiable data should not be in Prometheus. Mostly because it tends to be a cardinality problem.
Thanks,
Best regards.
> <mailto:prometheus-users+unsub...@googlegroups.com>.
--
You received this message because you are subscribed to the Google Groups "Prometheus Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to promethe...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-users/27f3c76c-f2b3-4bfe-87d7-02adbf61f8c4%40googlegroups.com.
-- Stuart Clark
--
You received this message because you are subscribed to the Google Groups "Prometheus Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to promethe...@googlegroups.com.
In our context, Prometheus is storing system metrics and business metrics, especially the number of accesses to the methods of our API.
{ "status":"success", "data":{ "resultType":"matrix", "result":[ { "metric":{ "__name__":"bea_nb_request", "action":"my_api_method", "instance":"bea:8081", "job":"bea" }, "values":[ [ 1585663440, "1" ], [ 1585663500, "2" ], [ 1585663560, "3" ], [ 1585663620, "3" ], [ 1585663680, "3" ], [ 1585663740, "3" ], [ 1585663800, "3" ], [ 1585663860, "3" ] ] }, others_api_methods... } ] }}
How are you storing the timestamp? Is that in a label or a metric value as the last call to the API?
In general these are sounding like you are trying to store events within Prometheus rather than metrics. Normally you'd not have a timestamp but a counter of the number of calls to the API.
No that sounds fairly normal. One thing to note is that those timestamps are not the times the methods were called. They are when Prometheus scraped your application. So if you scrape once a minute the actual call could have been at any point during that minute. Equally if there are multiple calls during that minute you'd have no idea when they happened either.
I'm not a lawyer or GDPR expert, but I think the type of extreme de-anonymisation you are suggesting is not generally something you'd be expected to be worrying about. Equally even if you do have an idea of who might have called an API there still isn't any personal data in Prometheus.
> an email to promethe...@googlegroups.com.