Storage - CAS Metrics
CAS metrics may be routed to varying types of databases for storage and analytics. The following options are available:
- Simple (In Memory)
- Graphite
- Ganglia
- JMX
- Atlas
- Signal FX
- Statsd
- InfluxDb
- Prometheus
- Wavefront
- New Relic
- CloudWatch
- …
Atlas
By default, metrics are exported to Atlas running on your local machine. The location of the Atlas server to use can be provided using:
The following settings and properties are available from the CAS configuration catalog:
management.metrics.export.atlas.batch-size=10000
Number of measurements per request to use for this backend. If more measurements are found, then multiple requests will be made.
|
management.metrics.export.atlas.config-refresh-frequency=10s
Frequency for refreshing config settings from the LWC service.
|
management.metrics.export.atlas.config-time-to-live=150s
Time to live for subscriptions from the LWC service.
|
management.metrics.export.atlas.config-uri=http://localhost:7101/lwc/api/v1/expressions/local-dev
URI for the Atlas LWC endpoint to retrieve current subscriptions.
|
management.metrics.export.atlas.connect-timeout=1s
Connection timeout for requests to this backend.
|
management.metrics.export.atlas.enabled=true
Whether exporting of metrics to this backend is enabled.
|
management.metrics.export.atlas.eval-uri=http://localhost:7101/lwc/api/v1/evaluate
URI for the Atlas LWC endpoint to evaluate the data for a subscription.
|
management.metrics.export.atlas.lwc-enabled=false
Whether to enable streaming to Atlas LWC.
|
management.metrics.export.atlas.meter-time-to-live=15m
Time to live for meters that do not have any activity. After this period the meter will be considered expired and will not get reported.
|
management.metrics.export.atlas.num-threads=4
Number of threads to use with the metrics publishing scheduler.
|
management.metrics.export.atlas.read-timeout=10s
Read timeout for requests to this backend.
|
management.metrics.export.atlas.step=1m
Step size (i.e. reporting frequency) to use.
|
management.metrics.export.atlas.uri=http://localhost:7101/api/v1/publish
URI of the Atlas server.
|
Configuration Metadata
The collection of configuration properties listed in this section are automatically generated from the CAS source and components that contain the actual field definitions, types, descriptions, modules, etc. This metadata may not always be 100% accurate, or could be lacking details and sufficient explanations.
Be Selective
This section is meant as a guide only. Do NOT copy/paste the entire collection of settings into your CAS configuration; rather pick only the properties that you need. Do NOT enable settings unless you are certain of their purpose and do NOT copy settings into your configuration only to keep them as reference. All these ideas lead to upgrade headaches, maintenance nightmares and premature aging.
YAGNI
Note that for nearly ALL use cases, declaring and configuring properties listed here is sufficient. You should NOT have to explicitly massage a CAS XML/Java/etc configuration file to design an authentication handler, create attribute release policies, etc. CAS at runtime will auto-configure all required changes for you. If you are unsure about the meaning of a given CAS setting, do NOT turn it on without hesitation. Review the codebase or better yet, ask questions to clarify the intended behavior.
Naming Convention
Property names can be specified in very relaxed terms. For instance cas.someProperty, cas.some-property, cas.some_property are all valid names. While all
forms are accepted by CAS, there are certain components (in CAS and other frameworks used) whose activation at runtime is conditional on a property value, where
this property is required to have been specified in CAS configuration using kebab case. This is both true for properties that are owned by CAS as well as those
that might be presented to the system via an external library or framework such as Spring Boot, etc.
When possible, properties should be stored in lower-case kebab format, such as cas.property-name=value.
The only possible exception to this rule is when naming actuator endpoints; The name of the
actuator endpoints (i.e. ssoSessions) MUST remain in camelCase mode.
Settings and properties that are controlled by the CAS platform directly always begin with the prefix cas. All other settings are controlled and provided
to CAS via other underlying frameworks and may have their own schemas and syntax. BE CAREFUL with
the distinction. Unrecognized properties are rejected by CAS and/or frameworks upon which CAS depends. This means if you somehow misspell a property definition
or fail to adhere to the dot-notation syntax and such, your setting is entirely refused by CAS and likely the feature it controls will never be activated in the
way you intend.
Validation
Configuration properties are automatically validated on CAS startup to report issues with configuration binding, specially if defined CAS settings cannot be
recognized or validated by the configuration schema. The validation process is on by default and can be skipped on startup using a special system
property SKIP_CONFIG_VALIDATION that should be set to true. Additional validation processes are also handled
via Configuration Metadata and property migrations applied automatically on
startup by Spring Boot and family.
Indexed Settings
CAS settings able to accept multiple values are typically documented with an index, such as cas.some.setting[0]=value. The index [0] is meant to be
incremented by the adopter to allow for distinct multiple configuration blocks.
Datadog
Datadog registry pushes metrics to datadoghq periodically. To export
metrics to Datadog, your API key must be provided:
The following settings and properties are available from the CAS configuration catalog:
management.metrics.export.datadog.api-key=
Datadog API key.
|
management.metrics.export.datadog.application-key=
Datadog application key. Not strictly required, but improves the Datadog experience by sending meter descriptions, types, and base units to Datadog.
|
management.metrics.export.datadog.batch-size=10000
Number of measurements per request to use for this backend. If more measurements are found, then multiple requests will be made.
|
management.metrics.export.datadog.connect-timeout=1s
Connection timeout for requests to this backend.
|
management.metrics.export.datadog.descriptions=true
Whether to publish descriptions metadata to Datadog. Turn this off to minimize the amount of metadata sent.
|
management.metrics.export.datadog.enabled=true
Whether exporting of metrics to this backend is enabled.
|
management.metrics.export.datadog.host-tag=instance
Tag that will be mapped to "host" when shipping metrics to Datadog.
|
management.metrics.export.datadog.num-threads=2
Deprecation status is |
management.metrics.export.datadog.read-timeout=10s
Read timeout for requests to this backend.
|
management.metrics.export.datadog.step=1m
Step size (i.e. reporting frequency) to use.
|
management.metrics.export.datadog.uri=https://api.datadoghq.com
URI to ship metrics to. Set this if you need to publish metrics to a Datadog site other than US, or to an internal proxy en-route to Datadog.
|
Configuration Metadata
The collection of configuration properties listed in this section are automatically generated from the CAS source and components that contain the actual field definitions, types, descriptions, modules, etc. This metadata may not always be 100% accurate, or could be lacking details and sufficient explanations.
Be Selective
This section is meant as a guide only. Do NOT copy/paste the entire collection of settings into your CAS configuration; rather pick only the properties that you need. Do NOT enable settings unless you are certain of their purpose and do NOT copy settings into your configuration only to keep them as reference. All these ideas lead to upgrade headaches, maintenance nightmares and premature aging.
YAGNI
Note that for nearly ALL use cases, declaring and configuring properties listed here is sufficient. You should NOT have to explicitly massage a CAS XML/Java/etc configuration file to design an authentication handler, create attribute release policies, etc. CAS at runtime will auto-configure all required changes for you. If you are unsure about the meaning of a given CAS setting, do NOT turn it on without hesitation. Review the codebase or better yet, ask questions to clarify the intended behavior.
Naming Convention
Property names can be specified in very relaxed terms. For instance cas.someProperty, cas.some-property, cas.some_property are all valid names. While all
forms are accepted by CAS, there are certain components (in CAS and other frameworks used) whose activation at runtime is conditional on a property value, where
this property is required to have been specified in CAS configuration using kebab case. This is both true for properties that are owned by CAS as well as those
that might be presented to the system via an external library or framework such as Spring Boot, etc.
When possible, properties should be stored in lower-case kebab format, such as cas.property-name=value.
The only possible exception to this rule is when naming actuator endpoints; The name of the
actuator endpoints (i.e. ssoSessions) MUST remain in camelCase mode.
Settings and properties that are controlled by the CAS platform directly always begin with the prefix cas. All other settings are controlled and provided
to CAS via other underlying frameworks and may have their own schemas and syntax. BE CAREFUL with
the distinction. Unrecognized properties are rejected by CAS and/or frameworks upon which CAS depends. This means if you somehow misspell a property definition
or fail to adhere to the dot-notation syntax and such, your setting is entirely refused by CAS and likely the feature it controls will never be activated in the
way you intend.
Validation
Configuration properties are automatically validated on CAS startup to report issues with configuration binding, specially if defined CAS settings cannot be
recognized or validated by the configuration schema. The validation process is on by default and can be skipped on startup using a special system
property SKIP_CONFIG_VALIDATION that should be set to true. Additional validation processes are also handled
via Configuration Metadata and property migrations applied automatically on
startup by Spring Boot and family.
Indexed Settings
CAS settings able to accept multiple values are typically documented with an index, such as cas.some.setting[0]=value. The index [0] is meant to be
incremented by the adopter to allow for distinct multiple configuration blocks.
Ganglia
By default, metrics are exported to Ganglia running on your local machine. The Ganglia server host and port to use can be provided using:
The following settings and properties are available from the CAS configuration catalog:
management.metrics.export.ganglia.addressing-mode=multicast
UDP addressing mode, either unicast or multicast.
|
management.metrics.export.ganglia.duration-units=milliseconds
Base time unit used to report durations.
|
management.metrics.export.ganglia.enabled=true
Whether exporting of metrics to Ganglia is enabled.
|
management.metrics.export.ganglia.host=localhost
Host of the Ganglia server to receive exported metrics.
|
management.metrics.export.ganglia.port=8649
Port of the Ganglia server to receive exported metrics.
|
management.metrics.export.ganglia.protocol-version=
Ganglia protocol version. Must be either 3.1 or 3.0.
Deprecation status is |
management.metrics.export.ganglia.rate-units=seconds
Base time unit used to report rates.
Deprecation status is |
management.metrics.export.ganglia.step=1m
Step size (i.e. reporting frequency) to use.
|
management.metrics.export.ganglia.time-to-live=1
Time to live for metrics on Ganglia. Set the multicast Time-To-Live to be one greater than the number of hops (routers) between the hosts.
|
Configuration Metadata
The collection of configuration properties listed in this section are automatically generated from the CAS source and components that contain the actual field definitions, types, descriptions, modules, etc. This metadata may not always be 100% accurate, or could be lacking details and sufficient explanations.
Be Selective
This section is meant as a guide only. Do NOT copy/paste the entire collection of settings into your CAS configuration; rather pick only the properties that you need. Do NOT enable settings unless you are certain of their purpose and do NOT copy settings into your configuration only to keep them as reference. All these ideas lead to upgrade headaches, maintenance nightmares and premature aging.
YAGNI
Note that for nearly ALL use cases, declaring and configuring properties listed here is sufficient. You should NOT have to explicitly massage a CAS XML/Java/etc configuration file to design an authentication handler, create attribute release policies, etc. CAS at runtime will auto-configure all required changes for you. If you are unsure about the meaning of a given CAS setting, do NOT turn it on without hesitation. Review the codebase or better yet, ask questions to clarify the intended behavior.
Naming Convention
Property names can be specified in very relaxed terms. For instance cas.someProperty, cas.some-property, cas.some_property are all valid names. While all
forms are accepted by CAS, there are certain components (in CAS and other frameworks used) whose activation at runtime is conditional on a property value, where
this property is required to have been specified in CAS configuration using kebab case. This is both true for properties that are owned by CAS as well as those
that might be presented to the system via an external library or framework such as Spring Boot, etc.
When possible, properties should be stored in lower-case kebab format, such as cas.property-name=value.
The only possible exception to this rule is when naming actuator endpoints; The name of the
actuator endpoints (i.e. ssoSessions) MUST remain in camelCase mode.
Settings and properties that are controlled by the CAS platform directly always begin with the prefix cas. All other settings are controlled and provided
to CAS via other underlying frameworks and may have their own schemas and syntax. BE CAREFUL with
the distinction. Unrecognized properties are rejected by CAS and/or frameworks upon which CAS depends. This means if you somehow misspell a property definition
or fail to adhere to the dot-notation syntax and such, your setting is entirely refused by CAS and likely the feature it controls will never be activated in the
way you intend.
Validation
Configuration properties are automatically validated on CAS startup to report issues with configuration binding, specially if defined CAS settings cannot be
recognized or validated by the configuration schema. The validation process is on by default and can be skipped on startup using a special system
property SKIP_CONFIG_VALIDATION that should be set to true. Additional validation processes are also handled
via Configuration Metadata and property migrations applied automatically on
startup by Spring Boot and family.
Indexed Settings
CAS settings able to accept multiple values are typically documented with an index, such as cas.some.setting[0]=value. The index [0] is meant to be
incremented by the adopter to allow for distinct multiple configuration blocks.
Graphite
By default, metrics are exported to Graphite running on your local machine. The Graphite server host and port to use can be provided using:
The following settings and properties are available from the CAS configuration catalog:
management.metrics.export.graphite.duration-units=milliseconds
Base time unit used to report durations.
|
management.metrics.export.graphite.enabled=true
Whether exporting of metrics to Graphite is enabled.
|
management.metrics.export.graphite.graphite-tags-enabled=
Whether Graphite tags should be used, as opposed to a hierarchical naming convention. Enabled by default unless "tagsAsPrefix" is set.
|
management.metrics.export.graphite.host=localhost
Host of the Graphite server to receive exported metrics.
|
management.metrics.export.graphite.port=2004
Port of the Graphite server to receive exported metrics.
|
management.metrics.export.graphite.protocol=pickled
Protocol to use while shipping data to Graphite.
|
management.metrics.export.graphite.rate-units=seconds
Base time unit used to report rates.
|
management.metrics.export.graphite.step=1m
Step size (i.e. reporting frequency) to use.
|
management.metrics.export.graphite.tags-as-prefix=
For the hierarchical naming convention, turn the specified tag keys into part of the metric prefix. Ignored if "graphiteTagsEnabled" is true.
|
Configuration Metadata
The collection of configuration properties listed in this section are automatically generated from the CAS source and components that contain the actual field definitions, types, descriptions, modules, etc. This metadata may not always be 100% accurate, or could be lacking details and sufficient explanations.
Be Selective
This section is meant as a guide only. Do NOT copy/paste the entire collection of settings into your CAS configuration; rather pick only the properties that you need. Do NOT enable settings unless you are certain of their purpose and do NOT copy settings into your configuration only to keep them as reference. All these ideas lead to upgrade headaches, maintenance nightmares and premature aging.
YAGNI
Note that for nearly ALL use cases, declaring and configuring properties listed here is sufficient. You should NOT have to explicitly massage a CAS XML/Java/etc configuration file to design an authentication handler, create attribute release policies, etc. CAS at runtime will auto-configure all required changes for you. If you are unsure about the meaning of a given CAS setting, do NOT turn it on without hesitation. Review the codebase or better yet, ask questions to clarify the intended behavior.
Naming Convention
Property names can be specified in very relaxed terms. For instance cas.someProperty, cas.some-property, cas.some_property are all valid names. While all
forms are accepted by CAS, there are certain components (in CAS and other frameworks used) whose activation at runtime is conditional on a property value, where
this property is required to have been specified in CAS configuration using kebab case. This is both true for properties that are owned by CAS as well as those
that might be presented to the system via an external library or framework such as Spring Boot, etc.
When possible, properties should be stored in lower-case kebab format, such as cas.property-name=value.
The only possible exception to this rule is when naming actuator endpoints; The name of the
actuator endpoints (i.e. ssoSessions) MUST remain in camelCase mode.
Settings and properties that are controlled by the CAS platform directly always begin with the prefix cas. All other settings are controlled and provided
to CAS via other underlying frameworks and may have their own schemas and syntax. BE CAREFUL with
the distinction. Unrecognized properties are rejected by CAS and/or frameworks upon which CAS depends. This means if you somehow misspell a property definition
or fail to adhere to the dot-notation syntax and such, your setting is entirely refused by CAS and likely the feature it controls will never be activated in the
way you intend.
Validation
Configuration properties are automatically validated on CAS startup to report issues with configuration binding, specially if defined CAS settings cannot be
recognized or validated by the configuration schema. The validation process is on by default and can be skipped on startup using a special system
property SKIP_CONFIG_VALIDATION that should be set to true. Additional validation processes are also handled
via Configuration Metadata and property migrations applied automatically on
startup by Spring Boot and family.
Indexed Settings
CAS settings able to accept multiple values are typically documented with an index, such as cas.some.setting[0]=value. The index [0] is meant to be
incremented by the adopter to allow for distinct multiple configuration blocks.
InfluxDb
By default, metrics are exported to Influx running on your local machine. The location of the Influx server to use can be provided using:
The following settings and properties are available from the CAS configuration catalog:
management.metrics.export.influx.api-version=
API version of InfluxDB to use. Defaults to 'v1' unless an org is configured. If an org is configured, defaults to 'v2'.
|
management.metrics.export.influx.auto-create-db=true
Whether to create the Influx database if it does not exist before attempting to publish metrics to it. InfluxDB v1 only.
|
management.metrics.export.influx.batch-size=10000
Number of measurements per request to use for this backend. If more measurements are found, then multiple requests will be made.
|
management.metrics.export.influx.bucket=
Bucket for metrics. Use either the bucket name or ID. Defaults to the value of the db property if not set. InfluxDB v2 only.
|
management.metrics.export.influx.compressed=true
Whether to enable GZIP compression of metrics batches published to Influx.
|
management.metrics.export.influx.connect-timeout=1s
Connection timeout for requests to this backend.
|
management.metrics.export.influx.consistency=one
Write consistency for each point.
|
management.metrics.export.influx.db=mydb
Database to send metrics to. InfluxDB v1 only.
|
management.metrics.export.influx.enabled=true
Whether exporting of metrics to this backend is enabled.
|
management.metrics.export.influx.num-threads=2
Deprecation status is |
management.metrics.export.influx.org=
Org to write metrics to. InfluxDB v2 only.
|
management.metrics.export.influx.password=
Login password of the Influx server. InfluxDB v1 only.
|
management.metrics.export.influx.read-timeout=10s
Read timeout for requests to this backend.
|
management.metrics.export.influx.retention-duration=
Time period for which Influx should retain data in the current database. For instance 7d, check the influx documentation for more details on the duration format. InfluxDB v1 only.
|
management.metrics.export.influx.retention-policy=
Retention policy to use (Influx writes to the DEFAULT retention policy if one is not specified). InfluxDB v1 only.
|
management.metrics.export.influx.retention-replication-factor=
How many copies of the data are stored in the cluster. Must be 1 for a single node instance. InfluxDB v1 only.
|
management.metrics.export.influx.retention-shard-duration=
Time range covered by a shard group. For instance 2w, check the influx documentation for more details on the duration format. InfluxDB v1 only.
|
management.metrics.export.influx.step=1m
Step size (i.e. reporting frequency) to use.
|
management.metrics.export.influx.token=
Authentication token to use with calls to the InfluxDB backend. For InfluxDB v1, the Bearer scheme is used. For v2, the Token scheme is used.
|
management.metrics.export.influx.uri=http://localhost:8086
URI of the Influx server.
|
management.metrics.export.influx.user-name=
Login user of the Influx server. InfluxDB v1 only.
|
Configuration Metadata
The collection of configuration properties listed in this section are automatically generated from the CAS source and components that contain the actual field definitions, types, descriptions, modules, etc. This metadata may not always be 100% accurate, or could be lacking details and sufficient explanations.
Be Selective
This section is meant as a guide only. Do NOT copy/paste the entire collection of settings into your CAS configuration; rather pick only the properties that you need. Do NOT enable settings unless you are certain of their purpose and do NOT copy settings into your configuration only to keep them as reference. All these ideas lead to upgrade headaches, maintenance nightmares and premature aging.
YAGNI
Note that for nearly ALL use cases, declaring and configuring properties listed here is sufficient. You should NOT have to explicitly massage a CAS XML/Java/etc configuration file to design an authentication handler, create attribute release policies, etc. CAS at runtime will auto-configure all required changes for you. If you are unsure about the meaning of a given CAS setting, do NOT turn it on without hesitation. Review the codebase or better yet, ask questions to clarify the intended behavior.
Naming Convention
Property names can be specified in very relaxed terms. For instance cas.someProperty, cas.some-property, cas.some_property are all valid names. While all
forms are accepted by CAS, there are certain components (in CAS and other frameworks used) whose activation at runtime is conditional on a property value, where
this property is required to have been specified in CAS configuration using kebab case. This is both true for properties that are owned by CAS as well as those
that might be presented to the system via an external library or framework such as Spring Boot, etc.
When possible, properties should be stored in lower-case kebab format, such as cas.property-name=value.
The only possible exception to this rule is when naming actuator endpoints; The name of the
actuator endpoints (i.e. ssoSessions) MUST remain in camelCase mode.
Settings and properties that are controlled by the CAS platform directly always begin with the prefix cas. All other settings are controlled and provided
to CAS via other underlying frameworks and may have their own schemas and syntax. BE CAREFUL with
the distinction. Unrecognized properties are rejected by CAS and/or frameworks upon which CAS depends. This means if you somehow misspell a property definition
or fail to adhere to the dot-notation syntax and such, your setting is entirely refused by CAS and likely the feature it controls will never be activated in the
way you intend.
Validation
Configuration properties are automatically validated on CAS startup to report issues with configuration binding, specially if defined CAS settings cannot be
recognized or validated by the configuration schema. The validation process is on by default and can be skipped on startup using a special system
property SKIP_CONFIG_VALIDATION that should be set to true. Additional validation processes are also handled
via Configuration Metadata and property migrations applied automatically on
startup by Spring Boot and family.
Indexed Settings
CAS settings able to accept multiple values are typically documented with an index, such as cas.some.setting[0]=value. The index [0] is meant to be
incremented by the adopter to allow for distinct multiple configuration blocks.
JMX
Micrometer provides a hierarchical mapping to JMX, primarily as a cheap and portable way to view metrics locally.
New Relic
New Relic registry pushes metrics to New Relic periodically. To export metrics to New Relic, your API key and account id must be provided:
The following settings and properties are available from the CAS configuration catalog:
management.metrics.export.newrelic.account-id=
New Relic account ID.
|
management.metrics.export.newrelic.api-key=
New Relic API key.
|
management.metrics.export.newrelic.batch-size=10000
Number of measurements per request to use for this backend. If more measurements are found, then multiple requests will be made.
|
management.metrics.export.newrelic.client-provider-type=
Client provider type to use.
|
management.metrics.export.newrelic.connect-timeout=1s
Connection timeout for requests to this backend.
|
management.metrics.export.newrelic.enabled=true
Whether exporting of metrics to this backend is enabled.
|
management.metrics.export.newrelic.event-type=SpringBootSample
The event type that should be published. This property will be ignored if 'meter-name-event-type-enabled' is set to 'true'.
|
management.metrics.export.newrelic.meter-name-event-type-enabled=false
Whether to send the meter name as the event type instead of using the 'event-type' configuration property value. Can be set to 'true' if New Relic guidelines are not being followed or event types consistent with previous Spring Boot releases are required.
|
management.metrics.export.newrelic.num-threads=2
Deprecation status is |
management.metrics.export.newrelic.read-timeout=10s
Read timeout for requests to this backend.
|
management.metrics.export.newrelic.step=1m
Step size (i.e. reporting frequency) to use.
|
management.metrics.export.newrelic.uri=https://insights-collector.newrelic.com
URI to ship metrics to.
|
Configuration Metadata
The collection of configuration properties listed in this section are automatically generated from the CAS source and components that contain the actual field definitions, types, descriptions, modules, etc. This metadata may not always be 100% accurate, or could be lacking details and sufficient explanations.
Be Selective
This section is meant as a guide only. Do NOT copy/paste the entire collection of settings into your CAS configuration; rather pick only the properties that you need. Do NOT enable settings unless you are certain of their purpose and do NOT copy settings into your configuration only to keep them as reference. All these ideas lead to upgrade headaches, maintenance nightmares and premature aging.
YAGNI
Note that for nearly ALL use cases, declaring and configuring properties listed here is sufficient. You should NOT have to explicitly massage a CAS XML/Java/etc configuration file to design an authentication handler, create attribute release policies, etc. CAS at runtime will auto-configure all required changes for you. If you are unsure about the meaning of a given CAS setting, do NOT turn it on without hesitation. Review the codebase or better yet, ask questions to clarify the intended behavior.
Naming Convention
Property names can be specified in very relaxed terms. For instance cas.someProperty, cas.some-property, cas.some_property are all valid names. While all
forms are accepted by CAS, there are certain components (in CAS and other frameworks used) whose activation at runtime is conditional on a property value, where
this property is required to have been specified in CAS configuration using kebab case. This is both true for properties that are owned by CAS as well as those
that might be presented to the system via an external library or framework such as Spring Boot, etc.
When possible, properties should be stored in lower-case kebab format, such as cas.property-name=value.
The only possible exception to this rule is when naming actuator endpoints; The name of the
actuator endpoints (i.e. ssoSessions) MUST remain in camelCase mode.
Settings and properties that are controlled by the CAS platform directly always begin with the prefix cas. All other settings are controlled and provided
to CAS via other underlying frameworks and may have their own schemas and syntax. BE CAREFUL with
the distinction. Unrecognized properties are rejected by CAS and/or frameworks upon which CAS depends. This means if you somehow misspell a property definition
or fail to adhere to the dot-notation syntax and such, your setting is entirely refused by CAS and likely the feature it controls will never be activated in the
way you intend.
Validation
Configuration properties are automatically validated on CAS startup to report issues with configuration binding, specially if defined CAS settings cannot be
recognized or validated by the configuration schema. The validation process is on by default and can be skipped on startup using a special system
property SKIP_CONFIG_VALIDATION that should be set to true. Additional validation processes are also handled
via Configuration Metadata and property migrations applied automatically on
startup by Spring Boot and family.
Indexed Settings
CAS settings able to accept multiple values are typically documented with an index, such as cas.some.setting[0]=value. The index [0] is meant to be
incremented by the adopter to allow for distinct multiple configuration blocks.
Prometheus
Prometheus expects to scrape or poll individual app instances for metrics. Spring Boot provides an actuator endpoint
available at /actuator/prometheus to present a Prometheus scrape with the appropriate format.
Here is an example scrape_config to add to prometheus.yml:
1
2
3
4
5
scrape_configs:
- job_name: 'spring'
metrics_path: '/actuator/prometheus'
static_configs:
- targets: ['HOST:PORT']
SignalFx
SignalFx registry pushes metrics to SignalFx periodically. To export metrics to SignalFx, your access token must be provided:
The following settings and properties are available from the CAS configuration catalog:
management.metrics.export.signalfx.access-token=
SignalFX access token.
|
management.metrics.export.signalfx.batch-size=10000
Number of measurements per request to use for this backend. If more measurements are found, then multiple requests will be made.
|
management.metrics.export.signalfx.connect-timeout=1s
Connection timeout for requests to this backend.
|
management.metrics.export.signalfx.enabled=true
Whether exporting of metrics to this backend is enabled.
|
management.metrics.export.signalfx.num-threads=2
Deprecation status is |
management.metrics.export.signalfx.read-timeout=10s
Read timeout for requests to this backend.
|
management.metrics.export.signalfx.source=
Uniquely identifies the app instance that is publishing metrics to SignalFx. Defaults to the local host name.
|
management.metrics.export.signalfx.step=10s
Step size (i.e. reporting frequency) to use.
|
management.metrics.export.signalfx.uri=https://ingest.signalfx.com
URI to ship metrics to.
|
Configuration Metadata
The collection of configuration properties listed in this section are automatically generated from the CAS source and components that contain the actual field definitions, types, descriptions, modules, etc. This metadata may not always be 100% accurate, or could be lacking details and sufficient explanations.
Be Selective
This section is meant as a guide only. Do NOT copy/paste the entire collection of settings into your CAS configuration; rather pick only the properties that you need. Do NOT enable settings unless you are certain of their purpose and do NOT copy settings into your configuration only to keep them as reference. All these ideas lead to upgrade headaches, maintenance nightmares and premature aging.
YAGNI
Note that for nearly ALL use cases, declaring and configuring properties listed here is sufficient. You should NOT have to explicitly massage a CAS XML/Java/etc configuration file to design an authentication handler, create attribute release policies, etc. CAS at runtime will auto-configure all required changes for you. If you are unsure about the meaning of a given CAS setting, do NOT turn it on without hesitation. Review the codebase or better yet, ask questions to clarify the intended behavior.
Naming Convention
Property names can be specified in very relaxed terms. For instance cas.someProperty, cas.some-property, cas.some_property are all valid names. While all
forms are accepted by CAS, there are certain components (in CAS and other frameworks used) whose activation at runtime is conditional on a property value, where
this property is required to have been specified in CAS configuration using kebab case. This is both true for properties that are owned by CAS as well as those
that might be presented to the system via an external library or framework such as Spring Boot, etc.
When possible, properties should be stored in lower-case kebab format, such as cas.property-name=value.
The only possible exception to this rule is when naming actuator endpoints; The name of the
actuator endpoints (i.e. ssoSessions) MUST remain in camelCase mode.
Settings and properties that are controlled by the CAS platform directly always begin with the prefix cas. All other settings are controlled and provided
to CAS via other underlying frameworks and may have their own schemas and syntax. BE CAREFUL with
the distinction. Unrecognized properties are rejected by CAS and/or frameworks upon which CAS depends. This means if you somehow misspell a property definition
or fail to adhere to the dot-notation syntax and such, your setting is entirely refused by CAS and likely the feature it controls will never be activated in the
way you intend.
Validation
Configuration properties are automatically validated on CAS startup to report issues with configuration binding, specially if defined CAS settings cannot be
recognized or validated by the configuration schema. The validation process is on by default and can be skipped on startup using a special system
property SKIP_CONFIG_VALIDATION that should be set to true. Additional validation processes are also handled
via Configuration Metadata and property migrations applied automatically on
startup by Spring Boot and family.
Indexed Settings
CAS settings able to accept multiple values are typically documented with an index, such as cas.some.setting[0]=value. The index [0] is meant to be
incremented by the adopter to allow for distinct multiple configuration blocks.
Memory
Micrometer ships with a simple, in-memory backend that is automatically used as a fallback if no other registry is configured. This allows you to see what metrics are collected in the metrics endpoint.
The in-memory backend disables itself as soon as you’re using any of the other available backend. You can also disable it explicitly:
The following settings and properties are available from the CAS configuration catalog:
management.metrics.export.simple.enabled=true
Whether exporting of metrics to this backend is enabled.
|
management.metrics.export.simple.mode=cumulative
Counting mode.
|
management.metrics.export.simple.step=1m
Step size (i.e. reporting frequency) to use.
|
Configuration Metadata
The collection of configuration properties listed in this section are automatically generated from the CAS source and components that contain the actual field definitions, types, descriptions, modules, etc. This metadata may not always be 100% accurate, or could be lacking details and sufficient explanations.
Be Selective
This section is meant as a guide only. Do NOT copy/paste the entire collection of settings into your CAS configuration; rather pick only the properties that you need. Do NOT enable settings unless you are certain of their purpose and do NOT copy settings into your configuration only to keep them as reference. All these ideas lead to upgrade headaches, maintenance nightmares and premature aging.
YAGNI
Note that for nearly ALL use cases, declaring and configuring properties listed here is sufficient. You should NOT have to explicitly massage a CAS XML/Java/etc configuration file to design an authentication handler, create attribute release policies, etc. CAS at runtime will auto-configure all required changes for you. If you are unsure about the meaning of a given CAS setting, do NOT turn it on without hesitation. Review the codebase or better yet, ask questions to clarify the intended behavior.
Naming Convention
Property names can be specified in very relaxed terms. For instance cas.someProperty, cas.some-property, cas.some_property are all valid names. While all
forms are accepted by CAS, there are certain components (in CAS and other frameworks used) whose activation at runtime is conditional on a property value, where
this property is required to have been specified in CAS configuration using kebab case. This is both true for properties that are owned by CAS as well as those
that might be presented to the system via an external library or framework such as Spring Boot, etc.
When possible, properties should be stored in lower-case kebab format, such as cas.property-name=value.
The only possible exception to this rule is when naming actuator endpoints; The name of the
actuator endpoints (i.e. ssoSessions) MUST remain in camelCase mode.
Settings and properties that are controlled by the CAS platform directly always begin with the prefix cas. All other settings are controlled and provided
to CAS via other underlying frameworks and may have their own schemas and syntax. BE CAREFUL with
the distinction. Unrecognized properties are rejected by CAS and/or frameworks upon which CAS depends. This means if you somehow misspell a property definition
or fail to adhere to the dot-notation syntax and such, your setting is entirely refused by CAS and likely the feature it controls will never be activated in the
way you intend.
Validation
Configuration properties are automatically validated on CAS startup to report issues with configuration binding, specially if defined CAS settings cannot be
recognized or validated by the configuration schema. The validation process is on by default and can be skipped on startup using a special system
property SKIP_CONFIG_VALIDATION that should be set to true. Additional validation processes are also handled
via Configuration Metadata and property migrations applied automatically on
startup by Spring Boot and family.
Indexed Settings
CAS settings able to accept multiple values are typically documented with an index, such as cas.some.setting[0]=value. The index [0] is meant to be
incremented by the adopter to allow for distinct multiple configuration blocks.
StatsD
The StatsD registry pushes metrics over UDP to a StatsD agent eagerly. By default, metrics are exported to a StatsD agent running on your local machine. The StatsD agent host and port to use can be provided using:
The following settings and properties are available from the CAS configuration catalog:
management.metrics.export.statsd.buffered=true
Whether measurements should be buffered before sending to the StatsD server.
|
management.metrics.export.statsd.enabled=true
Whether exporting of metrics to StatsD is enabled.
|
management.metrics.export.statsd.flavor=datadog
StatsD line protocol to use.
|
management.metrics.export.statsd.host=localhost
Host of the StatsD server to receive exported metrics.
|
management.metrics.export.statsd.max-packet-length=1400
Total length of a single payload should be kept within your network's MTU.
|
management.metrics.export.statsd.polling-frequency=10s
How often gauges will be polled. When a gauge is polled, its value is recalculated and if the value has changed (or publishUnchangedMeters is true), it is sent to the StatsD server.
|
management.metrics.export.statsd.port=8125
Port of the StatsD server to receive exported metrics.
|
management.metrics.export.statsd.protocol=udp
Protocol of the StatsD server to receive exported metrics.
|
management.metrics.export.statsd.publish-unchanged-meters=true
Whether to send unchanged meters to the StatsD server.
|
management.metrics.export.statsd.queue-size=2147483647
Deprecation status is |
management.metrics.export.statsd.step=1m
Step size to use in computing windowed statistics like max. To get the most out of these statistics, align the step interval to be close to your scrape interval.
|
Configuration Metadata
The collection of configuration properties listed in this section are automatically generated from the CAS source and components that contain the actual field definitions, types, descriptions, modules, etc. This metadata may not always be 100% accurate, or could be lacking details and sufficient explanations.
Be Selective
This section is meant as a guide only. Do NOT copy/paste the entire collection of settings into your CAS configuration; rather pick only the properties that you need. Do NOT enable settings unless you are certain of their purpose and do NOT copy settings into your configuration only to keep them as reference. All these ideas lead to upgrade headaches, maintenance nightmares and premature aging.
YAGNI
Note that for nearly ALL use cases, declaring and configuring properties listed here is sufficient. You should NOT have to explicitly massage a CAS XML/Java/etc configuration file to design an authentication handler, create attribute release policies, etc. CAS at runtime will auto-configure all required changes for you. If you are unsure about the meaning of a given CAS setting, do NOT turn it on without hesitation. Review the codebase or better yet, ask questions to clarify the intended behavior.
Naming Convention
Property names can be specified in very relaxed terms. For instance cas.someProperty, cas.some-property, cas.some_property are all valid names. While all
forms are accepted by CAS, there are certain components (in CAS and other frameworks used) whose activation at runtime is conditional on a property value, where
this property is required to have been specified in CAS configuration using kebab case. This is both true for properties that are owned by CAS as well as those
that might be presented to the system via an external library or framework such as Spring Boot, etc.
When possible, properties should be stored in lower-case kebab format, such as cas.property-name=value.
The only possible exception to this rule is when naming actuator endpoints; The name of the
actuator endpoints (i.e. ssoSessions) MUST remain in camelCase mode.
Settings and properties that are controlled by the CAS platform directly always begin with the prefix cas. All other settings are controlled and provided
to CAS via other underlying frameworks and may have their own schemas and syntax. BE CAREFUL with
the distinction. Unrecognized properties are rejected by CAS and/or frameworks upon which CAS depends. This means if you somehow misspell a property definition
or fail to adhere to the dot-notation syntax and such, your setting is entirely refused by CAS and likely the feature it controls will never be activated in the
way you intend.
Validation
Configuration properties are automatically validated on CAS startup to report issues with configuration binding, specially if defined CAS settings cannot be
recognized or validated by the configuration schema. The validation process is on by default and can be skipped on startup using a special system
property SKIP_CONFIG_VALIDATION that should be set to true. Additional validation processes are also handled
via Configuration Metadata and property migrations applied automatically on
startup by Spring Boot and family.
Indexed Settings
CAS settings able to accept multiple values are typically documented with an index, such as cas.some.setting[0]=value. The index [0] is meant to be
incremented by the adopter to allow for distinct multiple configuration blocks.
Wavefront
Wavefront registry pushes metrics to Wavefront periodically. If you are exporting metrics to Wavefront directly, your API token must be provided:
The following settings and properties are available from the CAS configuration catalog:
management.metrics.export.wavefront.api-token=
API token used when publishing metrics directly to the Wavefront API host.
|
management.metrics.export.wavefront.batch-size=10000
Number of measurements per request to use for this backend. If more measurements are found, then multiple requests will be made.
|
management.metrics.export.wavefront.connect-timeout=1s
Connection timeout for requests to this backend.
Deprecation status is |
management.metrics.export.wavefront.enabled=true
Whether exporting of metrics to this backend is enabled.
|
management.metrics.export.wavefront.global-prefix=
Global prefix to separate metrics originating from this app's instrumentation from those originating from other Wavefront integrations when viewed in the Wavefront UI.
|
management.metrics.export.wavefront.num-threads=2
Deprecation status is |
management.metrics.export.wavefront.read-timeout=10s
Read timeout for requests to this backend.
Deprecation status is |
management.metrics.export.wavefront.sender.flush-interval=1s
Interval at which points are flushed to the Wavefront server.
|
management.metrics.export.wavefront.sender.max-queue-size=50000
Maximum queue size of the in-memory buffer.
|
management.metrics.export.wavefront.sender.message-size=
Maximum message size, such that each batch is reported as one or more messages where no message exceeds the specified size.
|
management.metrics.export.wavefront.source=
Unique identifier for the app instance that is the source of metrics being published to Wavefront. Defaults to the local host name.
|
management.metrics.export.wavefront.step=1m
Step size (i.e. reporting frequency) to use.
|
management.metrics.export.wavefront.uri=https://longboard.wavefront.com
URI to ship metrics to.
|
Configuration Metadata
The collection of configuration properties listed in this section are automatically generated from the CAS source and components that contain the actual field definitions, types, descriptions, modules, etc. This metadata may not always be 100% accurate, or could be lacking details and sufficient explanations.
Be Selective
This section is meant as a guide only. Do NOT copy/paste the entire collection of settings into your CAS configuration; rather pick only the properties that you need. Do NOT enable settings unless you are certain of their purpose and do NOT copy settings into your configuration only to keep them as reference. All these ideas lead to upgrade headaches, maintenance nightmares and premature aging.
YAGNI
Note that for nearly ALL use cases, declaring and configuring properties listed here is sufficient. You should NOT have to explicitly massage a CAS XML/Java/etc configuration file to design an authentication handler, create attribute release policies, etc. CAS at runtime will auto-configure all required changes for you. If you are unsure about the meaning of a given CAS setting, do NOT turn it on without hesitation. Review the codebase or better yet, ask questions to clarify the intended behavior.
Naming Convention
Property names can be specified in very relaxed terms. For instance cas.someProperty, cas.some-property, cas.some_property are all valid names. While all
forms are accepted by CAS, there are certain components (in CAS and other frameworks used) whose activation at runtime is conditional on a property value, where
this property is required to have been specified in CAS configuration using kebab case. This is both true for properties that are owned by CAS as well as those
that might be presented to the system via an external library or framework such as Spring Boot, etc.
When possible, properties should be stored in lower-case kebab format, such as cas.property-name=value.
The only possible exception to this rule is when naming actuator endpoints; The name of the
actuator endpoints (i.e. ssoSessions) MUST remain in camelCase mode.
Settings and properties that are controlled by the CAS platform directly always begin with the prefix cas. All other settings are controlled and provided
to CAS via other underlying frameworks and may have their own schemas and syntax. BE CAREFUL with
the distinction. Unrecognized properties are rejected by CAS and/or frameworks upon which CAS depends. This means if you somehow misspell a property definition
or fail to adhere to the dot-notation syntax and such, your setting is entirely refused by CAS and likely the feature it controls will never be activated in the
way you intend.
Validation
Configuration properties are automatically validated on CAS startup to report issues with configuration binding, specially if defined CAS settings cannot be
recognized or validated by the configuration schema. The validation process is on by default and can be skipped on startup using a special system
property SKIP_CONFIG_VALIDATION that should be set to true. Additional validation processes are also handled
via Configuration Metadata and property migrations applied automatically on
startup by Spring Boot and family.
Indexed Settings
CAS settings able to accept multiple values are typically documented with an index, such as cas.some.setting[0]=value. The index [0] is meant to be
incremented by the adopter to allow for distinct multiple configuration blocks.