Findコマンドでfind 全ディレクトリを検索対象する方法を記述してます。ちなみに、locateはデータが肥大化するのが嫌なので、遅いけどfindを利用してます。. Metabase is an easy way to generate charts and dashboards, ask simple ad hoc queries without using SQL, and see detailed information about rows in your Database. You can set it up in under 5 minutes, and then give yourself and others a place to ask simple questions and understand the data your application is generating. What is Power BI? InfluxDB is meant for visualizing data by time, not by IDs like an order ID, and so it may need to be used in addition to a second database (such as MySQL, Postgresql or a NoSQL alternative) which can query by primary keys / IDs. Improve this answer. Follow answered Apr 5 at 15:26.
This is archived documentation for InfluxData product versions that are no longer maintained.For newer documentation, see the latest InfluxData documentation.
InfluxQL offers a full suite of administrative commands.
Data management
◦ Create a database withCREATE DATABASE
◦ Delete a database withDROP DATABASE
◦ Delete series withDROP SERIES
◦ Delete measurements withDROP MEASUREMENTRetention policy management
◦ Create retention policies withCREATE RETENTION POLICY
◦ Modify retention policies withALTER RETENTION POLICY
◦ Delete retention policies withDROP RETENTION POLICY
If you’re looking for SHOW queries (for example, SHOW DATABASES or SHOW RETENTION POLICIES), see Schema Exploration.
The examples in the sections below use InfluxDB’s Command Line Interface (CLI).You can also execute the commands using the HTTP API; simply send a GET request to the /query endpoint and include the command in the URL parameter q.See the Querying Data guide for more on using the HTTP API.
Note: When authentication is enabled, only admin users can execute most of the commands listed on this page.See the documentation on authentication and authorization for more information.
Data Management
Create a database with CREATE DATABASE
The CREATE DATABASE query takes the following form:
Create the database NOAA_water_database:
Create the database NOAA_water_database only if it doesn’t exist:
Create the database NOAA_water_database with a new retention policy called liquid:
When specifying a retention policy you can include one or more of the attributes DURATION, REPLICATION, and NAME.For more on retention policies, see Retention Policy Management
A successful CREATE DATABASE query returns an empty result. Nti audio port devices driver download for windows.
Note: Specifying a retention policy in the CREATE DATABASE query is available in InfluxDB versions 0.9.6+.
Delete a database with DROP DATABASE
The DROP DATABASE query deletes all of the data, measurements, series, continuous queries, and retention policies from the specified database.The query takes the following form:
Drop the database NOAA_water_database:
Drop the database NOAA_water_database only if it exists:
A successful DROP DATABASE query returns an empty result.
Delete series with DROP SERIES
The DROP SERIES query deletes all points from series in a database.The query takes the following form, where you must specify either the FROM clause or the WHERE clause:
Delete all series from a single measurement:
Delete series that have a specific tag set from a single measurement:
Delete all points in the series that have a specific tag set from all measurements in the database:
A successful DROP SERIES query returns an empty result.
DROP SERIES does not support time intervals in the WHERE clause.See GitHub Issue #1647 for more information).
Currently, InfluxDB does not support regular expressions with DROP SERIES.See GitHub Issue #4276 for more information.
Delete measurements with DROP MEASUREMENT
The DROP MEASUREMENT query deletes all data and series from the specified measurement and, unlike DROP SERIES, it also deletes the measurement from the index.The query takes the following form:
Delete the measurement h2o_feet:
Note:DROP MEASUREMENT drops all data and series in the measurement.It does not drop the associated continuous queries.
A successful DROP MEASUREMENT query returns an empty result.
Currently, InfluxDB does not support regular expressions with DROP MEASUREMENTS.See GitHub Issue #4275 for more information.
Retention Policy Management
The following sections cover how to create, alter, and delete retention policies.Note that when you create a database, InfluxDB automatically creates a retention policy named default which has infinite retention.You may disable that auto-creation in the configuration file.
Create retention policies with CREATE RETENTION POLICY
The CREATE RETENTION POLICY query takes the following form, where DEFAULT is optional:
DURATIONdetermines how long InfluxDB keeps the data - the options for specifying the duration of the retention policy are listed below.Note that the minimum retention period is one hour.mminuteshhoursddayswweeksINFinfiniteCurrently, the
DURATIONattribute supports only single units.For example, you cannot express the duration7230mas120h 30m.See GitHub Issue #3634 for more information.REPLICATIONdetermines how many independent copies of each point are stored in the cluster, wherenis the number of data nodes.DEFAULTsets the new retention policy as the default retention policy for the database.
Create a retention policy called one_day_only for the database NOAA_water_database with a one day duration and a replication factor of one:
Create the same retention policy as the one in the example above, but set it as the default retention policy for the database.
A successful CREATE RETENTION POLICY query returns an empty response.
Note: If you’re using InfluxDB versions 0.9.6+, you can also specify a new retention policy in the CREATE DATABASE query.See Create a database with CREATE DATABASE.
Modify retention policies with ALTER RETENTION POLICY
The ALTER RETENTION POLICY query takes the following form, where you must declare at least one of the retention policy attributes DURATION, REPLICATION, or DEFAULT:
First, create the retention policy what_is_time with a DURATION of two days:
Influxdb Dump
Modify what_is_time to have a three week DURATION and make it the DEFAULT retention policy for NOAA_water_database.
In the last example, what_is_time retains its original replication factor of 1.
A successful ALTER RETENTION POLICY query returns an empty result.
Delete retention policies with DROP RETENTION POLICY
Delete all measurements and data in a specific retention policy with:
Delete the retention policy what_is_time in the NOAA_water_database database:
A successful DROP RETENTION POLICY query returns an empty result.
Note: If you attempt DROP a retention policy that is the default retention policy for the database InfluxDB does not delete the policy and returns the error: ERR: retention policy is default.CREATE a new default policy or ALTER an already existing policy to be the default before deleting the retention policy.
Spring Boot Actuator is one of the most modified projects after the release of Spring Boot 2. It has been through major improvements, which aimed to simplify customization and include some new features like support for other web technologies, for example, the new reactive module – Spring WebFlux. Spring Boot Actuator also adds out-of-the-box support for exporting metrics to InfluxDB – an open-source time-series database designed to handle high volumes of timestamped data. It is really a great simplification in comparison to the version used with Spring Boot 1.5. You can see for yourself how much by reading one of my previous articles Custom metrics visualization with Grafana and InfluxDB. I described there how to export metrics generated by Spring Boot Actuator to InfluxDB using @ExportMetricsWriter bean. The sample Spring Boot application has been available for that article on GitHub repository sample-spring-graphite (https://github.com/piomin/sample-spring-graphite.git) in the branch master. For the current article, I have created the branch spring2 (https://github.com/piomin/sample-spring-graphite/tree/spring2), which show how to implement the same feature as before using version 2.0 of Spring Boot and Spring Boot Actuator.
Additionally, I’m going to show you how to use Spring Boot Actuator to export the same metrics to another popular monitoring system – Prometheus. There is one major difference between models of exporting metrics between InfluxDB and Prometheus. The first of them is a push based system, while the second is a pull based system. So, our sample application needs to actively send data to the InfluxDB monitoring system, while with Prometheus it only has to expose endpoints that will be fetched for data periodically. Let’s begin from InfluxDB.
1. Running InfluxDB
In the previous article I didn’t write much about this database and its configuration. The first step is typical for my examples – we will run a Docker container with InfluxDB. Here’s the simplest command that runs InfluxDB on your local machine and exposes HTTP API over 8086 port.
Once we started that container, you would probably want to login there and execute some commands. Nothing simpler, just run the following command and you would be able to do it. After login, you should see the version of InfluxDB running on the target Docker container.
The first step is to create a database. As you can probably guess, it can be achieved using the command create database. Then switch to the newly created database.
Does that semantic look familiar for you? InfluxDB provides a very similar query language to SQL. It is called InfluxQL, and allows you to define SELECT statements, GROUP BY or INTO clauses, and many more. However, before executing such queries, we should have data stored inside the database, am I right? Now, let’s proceed to the next steps in order to generate some test metrics.
2. Integrating Spring Boot Actuator with InfluxDB
If you include artifact micrometer-registry-influx to the project’s dependencies, an export to InfluxDB will be enabled automatically. Of course, we also need to include starter spring-boot-starter-actuator.
The only thing you have to do is to override the default address of InfluxDB because we are running InfluxDB a Docker container on VM. By default, Spring Boot Data tries to connect to a database named mydb. However, I have already created a database springboot, so I should also override this default value. In version 2 of Spring Boot all the configuration properties related to Spring Boot Actuator endpoints have been moved to management.* section.
You may be surprised a little after starting Spring Boot application with actuator included on the classpath, that it exposes only two HTTP endpoints by default /actuator/info and /actuator/health. That’s why in the newest version of Spring Boot all actuators other than /health and /info are disabled by default, for security purposes. To enable all the actuator endpoints, you have to set property management.endpoints.web.exposure.include to '*'.
In the newest version of Spring Boot monitoring of HTTP metrics has been improved significantly. We can enable collecting all Spring MVC metrics by setting the property management.metrics.web.server.auto-time-requests to true. Alternatively, when it is set to false, you can enable metrics for the specific REST controller by annotating it with @Timed. You can also annotate a single method inside the controller, to generate metrics only for specific endpoints.
After application boot you may check out the full list of generated metrics by calling endpoint GET /actuator/metrics. By default, metrics for Spring MVC controller are generated under the name http.server.requests. This name can be customized by setting the management.metrics.web.server.requests-metric-name property. If you run the sample application available inside my GitHub repository it is by default available under port 2222. Now, you can check out the list of statistics generated for a single metric by calling the endpoint GET /actuator/metrics/{requiredMetricName}, as shown in the following picture.
3. Building Spring Boot application
The sample Spring Boot application used for generating metrics consists of a single controller that implements basic CRUD operations for manipulating Person entity, repository bean and entity class. The application connects to MySQL database using Spring Data JPA repository providing CRUD implementation. Here’s the controller class.
Before running the application we have set up a MySQL database. The most convenient way to achieve it is through MySQL Docker image. Here’s the command that runs a container with database grafana, defines user and password, and exposes MySQL 5 on port 33306.
Then we need to set some database configuration properties on the application side. All the required tables will be created on application’s boot thanks to setting property spring.jpa.properties.hibernate.hbm2ddl.auto to update.
4. Generating metrics with Spring Boot Actuator
After starting the application and the required Docker containers, the only thing that needs to be is done is to generate some test statistics. I created the JUnit test class that generates some test data and calls endpoints exposed by the application in a loop. Here’s the fragment of that test method.
Now, let’s move back to step 1. As you probably remember, I have shown you how to run the influx client in the InfluxDB Docker container. After some minutes of working, the test unit should call exposed endpoints many times. We can check out the values of metric http_server_requests stored on Influx. The following query returns a list of measurements collected during the last 3 minutes.
As you see, all the metrics generated by Spring Boot Actuator are tagged with the following information: method, uri, status and exception. Thanks to that tag we may easily group metrics per single endpoint including failures and success percentage. Let’s see how to configure and view it in Grafana.
5. Metrics visualization using Grafana
Once we have exported succesfully metrics to InfluxDB, it is time to visualize them using Grafana. First, let’s run Docker container with Grafana.
Grafana provides a user friendly interface for creating influx queries. We define a graph that visualizes requests processing time per each of calling endpoints and the total number of requests received by the application. If we filter the statistics stored in the table http_server_requests by method type and uri, we would collect all metrics generated per single endpoint.
The similar definition should be created for the other endpoints. We will illustrate them all on a single graph.
Here’s the final result.
Here’s the graph that visualizes the total number of requests sent to the application.
6. Running Prometheus
The most suitable way to run Prometheus locally is obviously through a Docker container. The API is exposed under port 9090. We should also pass the initial configuration file and name of Docker network. Why? You will find all the answers in the next part of this step description.
In contrast to InfluxDB, Prometheus pulls metrics from an application. Therefore, we need to enable the Spring Boot Actuator endpoint that exposes metrics for Prometheus, which is disabled by default. To enable it, set property management.endpoint.prometheus.enabled to true, as shown on the configuration fragment below.
Then we should set the address of the Spring Boot Actuator endpoint exposed by the application in the Prometheus configuration file. A scrape_config section is responsible for specifying a set of targets and parameters describing how to connect with them. By default, Prometheus tries to collect data from the target endpoint once a minute.
Similarly for integration with InfluxDB we need to include the following artifact to the project’s dependencies.
In my case, Docker is running on VM, and is available under IP 192.168.99.100. If I would like Prometheus, which is launched as a Docker container, to be able to connect my application, I also should launch it as a Docker container. The most convenient way to link two independent containers is through the Docker network. If both containers are assigned to the same network, they would be able to connect to each other using the container’s name as a target address. Dockerfile is available in the root directory of the sample application’s source code. Second command visible below (docker build) is not required, because the required image piomin/person-service is available on my Docker Hub repository.
7. Integrate Prometheus with Grafana
Prometheus exposes a web console under address 192.168.99.100:9090, where you can specify query and display graphs with metrics. However, we can integrate it with Grafana to take an advantage of nicer visualization offered by this tool. First, you should create a Prometheus data source.
Then we should define queries for collecting metrics from Prometheus API. Spring Boot Actuator exposes three different metrics related to HTTP traffic: http_server_requests_seconds_count, http_server_requests_seconds_sum and http_server_requests_seconds_max. For example, we may calculate a per-second average rate of increase of the time series for http_server_requests_seconds_sum, that returns the total number of seconds spent on processing requests by using rate() function. The values can be filtered by method and uri using expression inside {}. The following picture illustrates configuration of rate() function per each endpoint.
Here’s the graph.
Summary
Delete Database In Influx
The improvement in metrics generation between version 1.5 and 2.0 of Spring Boot is significant. Exporting data to such popular monitoring systems like InfluxDB or Prometheus is now much easier than before with Spring Boot Actuator, and does not require any additional development. The metrics relating to HTTP traffic are more detailed and they may be easily associated with specific endpoints, thanks to tags indicating the uri, type and status of HTTP request. I think that modifications in Spring Boot Actuator in relation to the previous version of Spring Boot, could be one of the main motivations to migrate your applications to the newest version.