Information doesn't match with ExaOperation

[jorge-delgado-aera]

hello, I'm comparing the information collected by metrics vs information showed in exa operation and it doesn't match, could you guide me for this

[jakobbraun]

Hi, which information are you comparing?

[jorge-delgado-aera]

Persistent storage usage, storage size

[jakobbraun]

I see. The CloudWatch adapter copies the metrics from the Exasol system tables. First here some generic information: CloudWatch then aggregates them over the configured time window. You can see / configure the used aggregation function in the settings of the widget in the dashboard. In addition, the adapter converts the values from GiB to GB.

Could you please check if the values shown on your dashboard match with those from the statistic tables?

If that's the case, this integration works correctly. Then please open a support ticket to clarify the meaning of the numbers.

[jorge-delgado-aera]

thanks @jakobbraun, I checked the values in EXA_DB_SIZE_HOURLY and information match if I convert from GigaBytes (GB) to (Gigibytes), just another doubt, do you know why sometimes information is not showed if a select different timeframe, below an example of this

[jakobbraun]

The db size is only reported in certain intervals. If you pick a too small time-frame, CloudWatch does not see any reported value in that time window and can't show a value.

[jorge-delgado-aera]

hi @jakobbraun, could it be modified to collect temp_size and memory object size every one minute, my justification is that I' m programming alarms for this, usually users and applications use a lot of temp_size and I want to receive alarms in real time if total storage used is above of 90% for warning and 95% for critical, if these values are collected every 5 minutes or more it is time spent without any action in DB and it could provoke an outage, thanks in advance for all your help, REGARDS!

[redcatbear]

@jorge-delgado-aera, the Cloud Watch connector takes its data from Exasol's statistics tables by polling them. All statistical tables are aggregates over certain timeframes. The finest granularity is one hour.

There is a table EXA_STATISTICS_OBJECT_SIZES where the documentation seems to indicate that it holds the current value. But I suspect that once-per minute polling is going to be expensive. @jakobbraun, can you confirm my guess?

[jakobbraun]

I can totally understand your need for a higher time resolution here. The adapter copies those metrics from EXA_DB_SIZE_LAST_DAY. In fact, it polls from there once a minute, but the database only writes entries every 30 minutes. That's why also the adapter only reports a value in those intervals. So the only way to change this is to make the DB report the statistics more often. However, I checked this with our core-db team, and currently it's not possible to configure that. The only thing you can do is to open a support ticket to request more frequent statistics.

[exaSR]

The system tables in EXA_STATISTICS are meant to provide a stable timeline for retrospective analysis.

If your need goes more into operational monitoring, I would suggest you use non-aggregated "current value" sources like SYS.EXA_VOLUME_USAGE.

[jakobbraun]

I created a follow-up ticket: #69

[jakobbraun]

I'm closing this issue since the original question is solved.