Wso2 H2 MetricsDB

Wso2 uses MetricsDB to monitor the useful metrics in wso2 servers. The data stored in the MetricsDB are not critical for the server functionality but the data is very important to analyze the server performance when there is an issue. We can see the metrics and get an idea how the server behaved.

Enabling Metrics

 The metrics feature can be enabled from $CARBON_HOME/repository/conf/metrics.xml by making <Enabled>true</Enabled>. Also we can, use -Dmetrics.enabled=true at the server start up to enable Metrics feature without editing the metrics.xml configuration file.

View the Metrics DB in default h2

1. Uncomment the following lines in wso2 carbon.xml located in {Carbon_Home}/repository/conf.
    <H2DatabaseConfiguration>
        <property name="web" />
        <property name="webPort">8082</property>
        <property name="webAllowOthers" />
    </H2DatabaseConfiguration>
2. Restart the server
3. Access http://localhost:8082 using the browser.
4.Provide JDBC URL : jdbc:h2:repository/database/WSO2MetricsDB
                User Name: wso2carbon
                Password   : wso2carbon and connect to the database.
5.You can see five tables in the database as
       METRIC_COUNTER
       METRIC_GAUGE
       METRIC_HISTOGRAM
       METRIC_METER
       METRIC_TIMER


There are five types of metrics as below which are store in above tables.
  • Counter
  • Gauge
  • Histogram
  • Meter
  • Timer
There are five tables(mentioned above) for each metric type. The Carbon Metrics feature store data from each metric in this database. There is a JDBC Reporter running each one minute to store data in this database. The polling period can be configured from repository/conf/metrics.xml. There is also a clean up task to remove data older than 7 days. The ultimate purpose of monitoring these statistics is to get an idea about server performance.

Instead of the h2 database wso2 recommends to use a central database to store the metrics.

Move metrics DB to a centralized MySQL DB

Please use following steps to move metrics DB to a centralized MySQL DB.
  • Comment the h2 related datasource details from metrics-datasources.xml located in {IS_HOME}/repository/conf/datasources.
  • Uncomment MySQL related datasource from metrics-datasources.xml.
  • Create a database wso2_metrics in Mysql.
  • Provide the username and password in MySQL datasource accordingly.
  • Once you startup the server you can see the five tables have been created inside the wso2_metrics database in MySQL.
 

Comments

Post a Comment

Popular posts from this blog

Applying CORS Filter to wso2 Identity Server

When we are invoking an endpoint in oauth2 war from a javascript of a web app which is located in a different domain than identity server domain we are getting "No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://XXXXXXX is therefore not allowed access." The issue is occurring as the script on your page is running from a specifc domain and would try to request the resource via an XmlHttpRequest or XDomainRequst from a different domain as this is a cross -origin request. In order to get rid of this we need to enable this by sending below header using a custom filter.  Access-Control-Allow-Origin: http: //example.com   (Here  http://example.com is the domain name of where page with that script is hosted) Invoking UserInfo endpoint of wso2 Identity Server from JavaScript We have two possible solutions to apply the CORS header.  1. Customizing OpenIDConnectUserEndpoint.java as below and replacing the oau...
Read more

Secure Wso2 ESB REST APIs using Kerberos

Image
When a consumer attempts to consume a REST API, if the API is secured using some authentication protocol (e.g Basic , Kerberos, NTLM) the consumer has to prove his authentication to the API by sending credentials or relevant token through authorization headers. By default ESB REST APIs does not include any security and from this blog post I will speak about how to make the APIs secured using kerberos. I have used main 3 components ;  Active Directory as the KDC , ESB server as the resource server and a C#.net client to invoke the rest APIs in ESB server. The design of the implementation is as below. The Design of the Kerberos Communication 1. Client tries to invoke the ESB proxy 2. The server responds with 401 unauthorized 3. Client requests a kerberos service ticket from active directory 4. If user is identified by the KDC (AD) it will send the SGT to the client 5. Client wraps the SPENEGO token in the request HTTP header and resend to ESB 6. ESB sees the HTTP head...
Read more

DCR VS DCRM with WSO2 Identity server

Image
What is DCR (Dynamic Client Registration) Dynamic Client registration is a protocol which allows OAuth clients to register applications in an authorization server. Before this mechanism which is introduced from the spec [1] the client registration happened manually. With this implementation the client registration could be done in two ways.  - A client can be registered dynamically with the authorization server itself  - A programmer can register a client programmatically. Following is the protocol flow of DCR 1. A client sends a registration request with as follows. This should be a post request. 2. Server sends information response with 201 created. Request : POST   https://localhost:9443/api/identity/oauth2/dcr/v1.0/register HTTP/1.1 Authorization : Basic   YWRtaW46YWRtaW4= Content-Type :   application/json Content -Length :   114 Host: localhost :9443 {    "redirect_uris" : [    ...
Read more