<@U02SS3ZAMKQ> In the screenshot, it shows: "Your last call to change retention period to 7 days fai...
m
@Prashant Shahi In the screenshot, it shows: "Your last call to change retention period to 7 days failed. Please try again." However, it wouldn't allow me to retry with the same time interval, and my storage consumption has changed. This makes me feel Signoz has made some changes to the retention of logs. Is this a bug? I have set up Signoz before, and this behavior can be reproduced once the software collects a decent amount of data already (15-20GB+).
p
This is a bug from UI, which doesn’t let you retry same TTL. cc @Yunus M
Meanwhile, you can modify it to 8 days, and afterwards back to 7 days if needed
y
@Malik Bagwala : thanks for reporting the issue. Will fix it soon.
🙌 1
k
What has happened to me is that there is a network failure between the query service and clickhouse such that it thinks it failed but in reality clickhouse completes the retention change.
p
Updating TTL is a resource intensive operation. We recommend to stop ingestion and temporarily allot more resource to the node where clickhouse is running before proceeding with TTL updation with lots of data.
This is a limitation that is coming from ClickHouseDB itself.
m
@Prashant Shahi Is there any way to check if the TTL has been updated successfully or not? (Other than the UI)
p
yes, it is possible using the raw ClickHouse query. @Vishal Sharma would be right person to answer that.
m
@Vishal Sharma Just a reminder.
v
You can use below query to check TTL/retention:
Copy code
SELECT engine_full FROM system.tables WHERE name='logs' AND database='signoz_logs'
m
@Vishal Sharma Thanks a lot. For everyone else below is the improved version of the query which gives you ttl in seconds and in days
Copy code
SELECT
    toInt32(extract(engine_full, 'toIntervalSecond\\(([0-9]+)\\)')) AS ttl_in_seconds,
    ttl_in_seconds / 86400 AS ttl_in_days
FROM system.tables
WHERE (name = 'logs') AND (database = 'signoz_logs')
🙌 1