16 Historical Information
This section describes the configuration and management of historical information,
of which there are two types. Metrics about resource usage over time (trends) are
enabled with the
Metrics.Enabled setting. More discrete usage events are enabled
Metrics.Instrumentation setting. Both settings are
true, by default;
to disable either one, set it to
false in your configuration file.
16.1 Historical Metrics
RStudio Connect uses a separate
rserver-monitor process to record resource (CPU,
memory, etc.) usage over time. It is only active when historical metrics are
enabled. The customization settings described in the remainder of this section
have no effect when
Metrics.Enabled is off.
16.1.1 Historical Metrics Settings
Metrics data is written by default to a set of
RRD files. This data is stored by
/var/lib/rstudio-connect/metrics. You can specify
an alternate data path by using the
DataPath setting mentioned in
rserver-monitor process runs (by default) with the same user account
Connect uses to run its R processes. By default, this user account is
rstudio-connect (see the
RunAs setting in Section
A.17). You can specify an alternate user
account for the
rserver-monitor process by modifying the
User setting. See
Section A.22 for details.
RStudio Connect also supports logging of metrics to Graphite, and it supports disabling its default behavior of logging to RRD. Please see Section A.22 for more options for configuring the historical metrics in Connect.
16.1.2 Historical Metrics Process Management
Connect automatically spawns a process
rserver-monitor) to help maintain historical data. If this process exits, Connect will
restart it in an attempt to record as much historical information as possible. Connect
will delay restarting
rserver-monitor if it observes rapid, repeated failures.
rserver-monitor needs permission to write data to the metrics data directory, Connect
attempts to ensure the necessary permissions at startup. When Connect starts, it grants ownership
of the metrics data directory to the user account that will be used to start
16.1.3 Historical Metrics Process Logging
rserver-monitor process logs its output to syslog. If the process is unable to run,
you can check the system log (e.g.,
/var/log/syslog) for messages.
16.2 Historical Events
RStudio Connect can record event-style usage information which is intended to
answer questions like, “Who used my Shiny app and for how long?” This information
is stored in dedicated tables in the database. When using SQLite, this is handled
automatically by creating a second database file named from
-instrumentation appended. For PostgreSQL, a second, full database URL can
be provided in the
Postgres.InstrumentationURL setting. If it is not specified,
it will default to the value of
Postgres.URL. This allows you to store the
event data in the same place as the rest of the Connect information, in a different
schema, or even a different database, whichever meets your needs best. Please see
Section 9.2 for more details about using Postgres.
Note: There is currently no data retention policy so all data will always be kept. Data retention controls will be added in a future release.
Note: This data is not migrated by the
migrate tool (see 9.3).
The event information recorded by Connect is not currently presented in the dashboard or via an API.
16.2.1 Shiny Application Events
When a user opens a Shiny application, an event containing their user information and the length of their session will be logged to the instrumentation database.
16.2.2 RMD and Static Report Events
When a user visits an RMD or report page (such as a plot), an event containing their user information and information about the content visited will be logged to the instrumentation database.
16.2.3 User Login Events
When a user logs in to the Connect dashboard their user information will be logged to the instrumentation database.
16.2.4 Server Node Session Events
Note: Node session events may be erroneous if you have multiple nodes with the same hostname and do not reconfigure your node name, as explained below.
When a node is started, an event will be logged to the database containing a
node name, the server start time, and a periodically-updating heartbeat timestamp
indicating the length of the node’s running session. A node that exits cleanly
true to the
exited_cleanly column for its session.
false, it means either:
The node is still running. In this case, the heartbeat will continue to update.
rstudio-connectprocess was terminated with
SIGKILL, or the system lost power while the process was running. Confirm this by cross-referencing the node’s log file with the row for the session at issue. The log for that session will end abruptly in this case.
The node was terminated with
SIGINT, but did not successfully write to the database before being terminated with
SIGKILLor before the system lost power. Confirm this by cross-referencing the node’s log file, looking specifically for the line beginning with
Caught SIGINT/SIGTERM. The log for that session will end abruptly after that line in this case.
The node was terminated with
SIGINT, but couldn’t write to the database for some other reason. Confirm this by cross-referencing the node’s log file, looking specifically for
Error storing server exit time. The log for that session will contain that line in this case.
The node name defaults to the node’s hostname, but can be changed using the
Server.NodeName configuration setting or the
environment variable. The node name MUST be unique for every node in your
cluster. RStudio Connect cannot detect duplicate node names at this time,
including the situation where multiple nodes have the same hostname.
The heartbeat timestamp can be changed from its default of
30m by setting
Metrics.InstrumentationServerHeartbeat to another duration.