Here are the basic and simple usages of the MeterSystem APIs.
## Meter Creation
New meter could be created based on metrics name, function, scope and data type.
1. Metrics name is still the storage entity name.
2. Functions are every similar with the OAL function, just accepting different input.
```java
final MeterSystem meterSystem = MeterSystem.meterSystem(getManager());
meterSystem.create("test_long_metrics", "avg", ScopeType.SERVICE, Long.class);
```
NOTICE, this creation should only be called in the `module#prepare` stage, otherwise, `Can't create new metrics anymore` exception will be raised after the **CORE** module `start` stage finished. You may find out, there is a chance `create` could be executed successfully in your own `module#start` stage, but it it just because of the sequence of provider loaded by the class loader, **no guarantee, so please don't do that**.
## Runtime Calculation
`AcceptableValue` is the object created at the runtime to accept new metrics value.
```java
final MeterSystem service = getManager().find(CoreModule.NAME).provider().getService(MeterSystem.class);
Executors.newSingleThreadScheduledExecutor().scheduleAtFixedRate(new Runnable() {
@Override
public void run() {
final AcceptableValue<Long> value = service.buildMetrics("test_long_metrics", Long.class);
value.accept(MeterEntity.newService("abc"), 5L);
value.setTimeBucket(TimeBucket.getMinuteTimeBucket(System.currentTimeMillis()));
service.doStreamingCalculation(value);
}
}, 2, 2, TimeUnit.SECONDS);
```
## Meter Functions
Right now, only `avg` function has been implemented. I submit this PR as soon as possible to get your feedback. I will add more functions.
## Notice
1. Make slow trace query available in the sampled record. Logically, they are the same thing. The UI doesn't need to concern about the trace as a special case.
2. Endpoint dependency will be removed from the dashboard. Because no query available for it. We will provide a new page for that in 8.1
3. Comparison page will be removed due to dashboard is powerful enough to replace it.
Motivation:
Review code styles with some bots automatically.
Modifications:
Set up ReviewDog in GitHub Action to review code style.
Add more check rules to checkstyle plugin.
Result:
Obvious code styles can be reviewed and commented automatically.
* Provide profile task downstream to sniffer
* fix agent unit testcase issue
* add profile switch config on sniffer
* fix es error
* 1. add @DefaultImplementor on the sniffer profile task service
2. change ProfileTaskExecutionService#PROFILE_TASK_READY_SCHEDULE to final and remove volatile
2. fix style error
* change timeFromStartMills use `<` to compare
* 1. add `maxSamplingCount` to profile task
2. make profile task limit to the common package
* 1. change `agent.active_profile` to `profile.active` and make true on default
2. add `maxSamplingCount` in profile task
3. use `createTime` to check has new command list
4. add task re-check before process profile task
* 1. add `profile-receiver` document
2. change `ProfileTaskExecutionService` use single schedule thread pool
3. cache dont need fetch data when no data, use auto-fresh mechanism only
* remove navigate time judge, fix comment wrong meaning
* [Feature] Officially support ElasticSearch 7 as backend storage
* Extract bootstrap module to be shared by multiple starters
* Add missing configuration file and distinguish different version in test
* Update known-oap-backend-dependencies-es7.txt
Update the dependency lib
* Fix missing adaptation to ElasticSearch 7
* Rename ElasticSearch 7 specific class with Es7 infix
* Fix miss-adapted ElasticSearch DAO API
* Add ES7 specific configuration and polish documentations
* Polish documentations
* Polish documentations
吴晟 Wu Sheng
Jared Tan
Daming
kezhenxu94
mrproliu
Gao Hongtao