<!-- This file was generated automatically.
     Do not edit it: it is likely to be discarded and generated again before it's read next time.
     Files used to generate this file:
       /var/tmp/omicron_tmp/omicron_nexus-841e1fd6fbb51d9c-test_switch1_comes_up_late.16170.1-clickhouse-xL4Xkg/config.xml      -->

<clickhouse>
    <logger>
        <level>information</level>
        <console>true</console>
    </logger>

    <query_log>
        <database>system</database>
        <table>query_log</table>
        <engine>Engine = MergeTree ORDER BY event_time TTL event_date + INTERVAL 7 DAY</engine>
        <flush_interval_milliseconds>10000</flush_interval_milliseconds>
    </query_log>

    <!--
        Mask long queries generated by oximeter.

        As of this writing, oximeter builds queries like

            SELECT * FROM oximeter.measurements_* WHERE timeseries_key IN (...)

        where the IN clause contains thousands of elements. A single oximeter
        query can generate multiple queries of this form. We observe that
        these queries comprise ~80% of the `system.query_log` table, which is
        itself one of the largest tables in terms of compressed disk use.
        This block truncates this long query pattern, since it's not
        operationally useful and consumes a significant amount of disk.

        Note: this rule will become irrelevant if we change the metrics
        data model in clickhouse.
    -->
    <query_masking_rules>
        <rule>
            <name>truncate large timeseries_key IN clauses</name>
            <regexp>(\btimeseries_key\s+IN\s*\()[^)]{120,}\)</regexp>
            <replace>\1...)</replace>
        </rule>
    </query_masking_rules>

    <metric_log>
        <database>system</database>
        <table>metric_log</table>
        <!--
            TTL will be 30 days until we've finished long running tests.
            After that, we can reduce it to a week or two.
        -->
        <engine>Engine = MergeTree ORDER BY event_time TTL event_date + INTERVAL 30 DAY</engine>
        <flush_interval_milliseconds>7500</flush_interval_milliseconds>
        <collect_interval_milliseconds>1000</collect_interval_milliseconds>
        <max_size_rows>1048576</max_size_rows>
        <reserved_size_rows>8192</reserved_size_rows>
        <buffer_size_rows_flush_threshold>524288</buffer_size_rows_flush_threshold>
        <flush_on_crash>false</flush_on_crash>
    </metric_log>

    <asynchronous_metric_log>
        <database>system</database>
        <table>asynchronous_metric_log</table>
        <!--
            TTL will be 30 days until we've finished long running tests.
            After that, we can reduce it to a week or two.
        -->
        <engine>Engine = MergeTree ORDER BY event_time TTL event_date + INTERVAL 30 DAY</engine>
        <flush_interval_milliseconds>7500</flush_interval_milliseconds>
        <collect_interval_milliseconds>1000</collect_interval_milliseconds>
        <max_size_rows>1048576</max_size_rows>
        <reserved_size_rows>8192</reserved_size_rows>
        <buffer_size_rows_flush_threshold>524288</buffer_size_rows_flush_threshold>
        <flush_on_crash>false</flush_on_crash>
    </asynchronous_metric_log>

    <mlock_executable>true</mlock_executable>

    <tcp_port>9000</tcp_port>

    <users>
        <default>
            <password/>

            <networks>
                <ip>::/0</ip>
            </networks>

            <profile>default</profile>
            <quota>default</quota>
            <access_management>1</access_management>
        </default>
    </users>

    <profiles>
        <default>
            <!--
                Omit logs for fast queries. As of this writing, the vast
                majority of clickhouse queries are INSERTS that succeed in
                <5ms, and aren't operationally interesting. From a test rack:

                    SELECT
                        roundToExp2(greatest(query_duration_ms, 1)) AS bucket_start,
                        bucket_start * 2 AS bucket_end,
                        count() AS count,
                        round((100 * count()) / (
                            SELECT count()
                            FROM system.query_log
                        ), 4) AS pct
                    FROM system.query_log
                    GROUP BY bucket_start, bucket_end
                    ORDER BY bucket_start ASC

                        ┌─bucket_start─┬─bucket_end─┬───count─┬─────pct─┐
                     1. │            1 │          2 │ 3590120 │ 62.6491 │
                     2. │            2 │          4 │ 1206074 │ 21.0465 │
                     3. │            4 │          8 │  298972 │  5.2172 │
                     4. │            8 │         16 │  109739 │   1.915 │
                     5. │           16 │         32 │  114881 │  2.0047 │
                     6. │           32 │         64 │  121448 │  2.1193 │
                     7. │           64 │        128 │  130456 │  2.2765 │
                     8. │          128 │        256 │   87336 │  1.5241 │
                     9. │          256 │        512 │   57767 │  1.0081 │
                    10. │          512 │       1024 │   12327 │  0.2151 │
                    11. │         1024 │       2048 │    1341 │  0.0234 │
                    12. │         2048 │       4096 │      56 │   0.001 │
                    13. │         4096 │       8192 │       1 │       0 │
                        └──────────────┴────────────┴─────────┴─────────┘
            -->
            <log_queries_min_query_duration_ms>5</log_queries_min_query_duration_ms>
        </default>
    </profiles>

    <quotas>
        <default/>
    </quotas>

    <merge_tree>
        <ratio_of_defaults_for_sparse_serialization>1.0</ratio_of_defaults_for_sparse_serialization>
    </merge_tree>
</clickhouse>
