# Server The server is a critical component of the Flopsar software ecosystem. It is responsible for managing the entire environment, collecting data from agents, and serving this data to users of the Workstation application. **Key Responsibilities:** 1. **Environment Management**: * The server orchestrates and monitors the operation of the entire Flopsar environment. It handles the configuration and coordination of agents, manages data flows, and ensures seamless communication between different components. 2. **Data Collection**: * The server aggregates data collected by agents deployed across various systems and applications. This data may include performance metrics, logging information, and other telemetry data. The server processes and stores this information for further analysis and visualization. 3. **Data Serving**: * The server provides a backend for the Workstation application, delivering real-time and historical data to users. It supports querying and filtering capabilities, enabling users to access detailed information and insights about the performance and behavior of their applications. Overall, the server plays a pivotal role in ensuring that the Flopsar system operates efficiently, providing a robust platform for data collection and analysis, and supporting effective decision-making and monitoring for users. ## CLI The Flopsar server has a few command line options. All the available options of the server can be listed by executing the command: ```shell-session $ flopsar-server --help ``` ## Configuration All the server settings are configured in a file `settings.yml`. This file contains the following default settings: {% code title="settings.yml" fullWidth="false" %} ```yaml eula: false name: my environment data: /change/me max_ext_size: 1MiB req_timeout: 3m xstack_maxsize: 3000 agent: server_ip: 0.0.0.0 server_port: 9000 ui_srv: server_ip: 0.0.0.0 server_port: 9443 ssl: false otlp: enable: true http: server_ip: 0.0.0.0 server_port: 4318 grpc: server_ip: 0.0.0.0 server_port: 4317 ssl : false ssl: cert: server.crt key: server.pem logger: backend: Local max_size: 50MiB max_files: 5 archive: enable: false policy: purge start_at: 03:00:00.0 retention: 3days compression: parameters: false exceptions: false pass_policy: enable: false min_len: 8 digits: false special_chars: false capital_letters: false forbidden_chars: '' ``` {% endcode %} #### `eula` This option must be set to `true`, otherwise the server will not run. This is the [EULA](https://releases.flopsar.com/#/eula) accept flag. #### `name` Name of the environment. #### `data` This option sets a path to the Flopsar environment directory. #### `max_ext_size` This option sets a maximal size of an extension jar file. #### `req_timeout` Maximal request time after which the server drops the request. #### `xstack_maxsize` Maximal number of invocations within a single execution stack. #### `agent` This option sets a server socket address, which is used by agents to connect to the server. * `server_ip` - specifies the IP address (CIDR format), on which the server is to listen for TCP/IP connections from agents. Only agents should connect to this address. If you want the server to listen on all interfaces, put `0.0.0.0` value. * `server_port` - specifies the IP port, on which the server is to listen for TCP/IP connections from agents. #### `ui_srv` This option sets a server socket address, which is used by workstation clients to connect to the server. * `server_ip` - specifies the IP address (CIDR format), on which the server is to listen for TCP/IP connections from workstation clients. Only workstation clients should connect to this address. * `server_port` - specifies the IP port, on which the server is to listen for TCP/IP connections from workstation clients. * `ssl` - switches on/off encryption on the workstation clients connections. #### `otlp` This option manages [OpenTelemetry](https://opentelemetry.io/) feature. Currently, Flopsar supports only [traces](https://opentelemetry.io/docs/concepts/signals/traces/). Flopsar acts as an OpenTelemetry backend. It supports [OTLP](https://opentelemetry.io/docs/specs/otlp/) protocol. Please, refer to [OpenTelemetry documentation](https://opentelemetry.io/docs/) for more details. * `enable` - enables/disables the OpenTelemetry feature. * `http` - [OTLP/HTTP](https://opentelemetry.io/docs/specs/otlp/#otlphttp) support for binary-encoded [Protobuf](https://protobuf.dev/) format. * `server_ip` - specifies the IP address (CIDR format), on which the server is to listen for OpenTelemetry data. If you want the server to listen on all interfaces, put `0.0.0.0` value. * `server_port` - specifies the IP port, on which the server is to listen for TCP/IP connections from agents. * `grpc` - [OTLP/gRPC](https://opentelemetry.io/docs/specs/otlp/#otlpgrpc) support or binary-encoded [Protobuf](https://protobuf.dev/) format. * `server_ip` - specifies the IP address (CIDR format), on which the server is to listen for OpenTelemetry data. If you want the server to listen on all interfaces, put `0.0.0.0` value. * `server_port` - specifies the IP port, on which the server is to listen for TCP/IP connections from agents. * `ssl` - switches on/off encryption off the gRPC connections. {% hint style="info" %} Please note, you need a license which enables the OpenTelemetry feature. {% endhint %} #### `ssl` This option switches on/off encryption. Please note, agent-server connections are not encrypted. * `cert` - the server certificate file name. * `key` - the server private key file name. The SSL files must be stored in the `ssl` directory. #### `logger` This option manages the server logger. * `backend` - one of the two backend for loggers: `Local` or `Syslog`. * When `Local` is specified, the server log files will be stored in the `log` directory. * When `Syslog` is specified, the logs will be managed by the syslog. In this case, both options `max_size` and `max_files` are ignored. * `max_size` - maximal size a logger file can reach. When the value is reached, the logger file is rolled. * `max_files` - maximal number of logger files. The oldest file is overwritten, so that the maximal number files is maintained according to this option value. #### `archive` This option manages [data archiving](#data-archiving). * `enable` - if set to `true`, enables the data archiving feature. If set to `false`, disables it. * `policy` - if set to `purge`, removes all the old data. If set to `archive`, backup the data. * `start_at` - sets a time of day the archive procedure should start. The time of day is specified in the format `HH:MM:SS.m` * `retention` - sets the data retention. #### `compression` This option enables/disables data compression in the database. * `parameters` - if set to `true`, enables the compression for parameters data. If set to `false`, disables it. * `exceptions` - if set to `true`, enables the compression for exceptions data. If set to `false`, disables it. #### **`pass_policy`** This option allows you to configure the password requirements for your system. It provides several parameters to define the desired policy. * `enable` - if set to `true`, enables the passwords policy feature. If set to `false`, disables it. * `min_len` - sets a requirement for the minimal password length. * `digits` - if set to `true`, passwords must have at least one digit. * `special_chars` - if set to `true`, passwords must have at least one special character. * `capital_letters` - If set to true, passwords must have at least one capital letter. * `forbidden_chars` - this parameter allows you to specify a list of characters that are not allowed in passwords. If any of the specified characters are found in a password, it will be considered invalid. If the parameter is empty, all characters are allowed in passwords. ## OpenTelemetry As of this version, Flopsar partially supports OpenTelemetry, specifically handling only traces. To store data in the Flopsar database, you need to configure your environment to send data to the Flopsar database. Both environments with and without an OpenTelemetry collector are supported. ### Collecter In environments that utilize an OpenTelemetry [collector](https://opentelemetry.io/docs/collector/), you must define an additional OTLP (OpenTelemetry Protocol) exporter in the collector configuration. This exporter should be used in the service to send data to the Flopsar database. #### Steps to Configure OpenTelemetry Collector 1. **Define the OTLP Exporter:** Add an OTLP exporter configuration in your OpenTelemetry collector configuration file. The exporter should be set up to point to your Flopsar database endpoint. 2. **Use the OTLP Exporter in Service:** Ensure that the service section of your OpenTelemetry collector configuration references the newly defined OTLP exporter. This will enable the collector to forward trace data to the Flopsar database. #### Example Configuration Here is an example [configuration](https://opentelemetry.io/docs/collector/configuration/) snippet for an OpenTelemetry collector to add an OTLP exporter for Flopsar: {% code fullWidth="false" %} ```yaml exporters: otlp/flopsar: endpoint: "" tls: insecure: true service: pipelines: traces: exporters: [otlp/flopsar] ``` {% endcode %} Replace `` with the actual endpoint of your Flopsar database. ### No Collector If you prefer not to use the OpenTelemetry collector, you can send data directly from agents to the Flopsar server. This requires setting at least two environment variables, so that your application process can read them. * [`OTEL_EXPORTER_OTLP_ENDPOINT`](https://opentelemetry.io/docs/languages/sdk-configuration/otlp-exporter/#otel_exporter_otlp_endpoint) * [`OTEL_SERVICE_NAME`](https://opentelemetry.io/docs/languages/sdk-configuration/general/#otel_service_name) Additionally, you may set the following options, which prevent the agent from sending both metrics and logs: * `OTEL_LOGS_EXPORTER=none` * `OTEL_METRICS_EXPORTER=none` #### Example For example, you can add these [options](https://opentelemetry.io/docs/zero-code/java/agent/getting-started/) for your JVM startup arguments: ```sh java -javaagent:path/to/opentelemetry-javaagent.jar -Dotel.service.name= -Dotel.exporter.otlp.endpoint=http://: -Dotel.metrics.exporter=none -Dotel.logs.exporter=none ``` where `OTLP.HTTP.*` values are taken from the [settings](#configuration). ## Storage Flopsar makes use of a hybrid approach, which incorporates both SQL database and a custom engine storage. The engine storage is used to store the data while the SQL datatabse to store configuration data. ### Data Archiving The Data Archiving feature serves as a valuable tool to effectively manage the volume of your database. By enabling this feature, a daily execution is scheduled at the specified time. This process, governed by the chosen policy, facilitates either data purging or data archiving. To exclusively retain recent data while disregarding older records, simply configure the system to adopt the `purge` policy as specified in the configuration file. Alternatively, opt for the `archive` policy, which entails compressing the data and relocating it to the designated `/arch` directory. The archived data is stored within a zip file, encompassing invocations, key-value data, and their corresponding symbols. ### Data Restoring All the archive files can be used to restore the Flopsar environment. Suppose you have the `ARCHIVE.zip` file created during the archive procedure. You will need the workstation application also. In order to create a new local environment, just to explore the archive data, you must execute the following command: ```shell-session $ flopsar-server create --archive ARCHIVE.zip --app flopsar-workstation.zip ``` This operation will create a new environment in the `` directory. To access this environment, you must execute the following command: ```shell-session $ flopsar-server local ``` This command will start the Flopsar server in a `local` mode, which is used only for data access purposes. Then you should be able to access the environment at the address