Gathering logs in VMware Data Services Manager v1.5
The ability to gather logs is an essential part of troubleshooting any product. Logs can help you to resolve issues on your own, but may also be necessary should you need to engage with a technical support organizations. In this post, we will look at the various log bundles which can be gathered from a VMware Data Services Manager (DSM) deployment. We will see the different logs associated with the different layers of VMware DSM. We will also examine which roles have permissions to gather the various log bundles.
Roles in VMware DSM
Let’s begin with a review of the different roles in VMware Data Services Manager. This isn’t a complete listing of privileges, but does show some of the tasks associated with each role.
| Provider Admin | Organization Admin | Organization User |
| Member of Provider Organization, automatically, created during setup of Provider appliance
Creates and manages Tenant Organizations, Org Admins, and Org Users Manages resources such as Environments, Namespaces, VM Plans and database templates Generate system / provider, agent & database log bundles May also carry out tasks typically associated with Org Admin and Org User, if necessary |
Manages Org Users in a Tenant Organization
Visibility into Environment and Namespace resources Permissions to manage databases in a Tenant Organization on behalf of Org User, and assign database ownership Generate agent & database log bundles May also carry out tasks typically associated with Org User, if necessary |
Manages databases in a Tenant Organization
Visibility into Environment and Namespace resources Perform database management operations such as create, monitor, backup, clone, restore, recover, upgrade, delete Generate agent and database log bundles |
System Logs
Let’s begin with the System Logs, also known as the Provider Logs. These are the logs gathered on the Provider appliance. System Logs may only be gathered by the Provider Admin. The System Logs view is not available to Org Admins or to Org Users. The option to trigger a system log bundle is available in the main menu for Provider Admins only. When the log bundle has been downloaded and extracted, various folder relating to the main architectural features of the provider appliance are visible. These include the Rabbitmq messaging service as well as the nginx web server and reverse proxy. Also captured are information from the various databases used by the provider, such as a Redis KV store caching database and a PostgreSQL database.
Environment / Agent Logs
If there is a need to troubleshoot interactions between DSM and the vSphere environment that is being used as a destination for provisioning databases, agent logs may be generated. The logs can be captured by both an Org Admin or by an Org User from the Environment view. In previous versions, agents were always a separate virtual appliance. However, since the release of v1.5, a new consolidated deployment model exists where the provider and the agent are part of the same appliance. This is perfect for smaller deployments of DSM. For larger deployments, which span multiple vSphere infrastructures, standalone agent appliances still need to be provisioned.
Note that when an agent log bundle is being captured, the person generating the log bundle is prompted to make a selection. They can select to capture agent appliance logs and also logs from any databases that they wish to include in the log bundle. Note that users can only capture database log bundles from databases that they are the owner of. Thus, they can elect to either gather agent logs, database logs or gather both sets of logs.
Below, the logs are being captured by an Org Admin. Once downloaded and extracted, it is possible to see the logs of the main architectural components of an agent. These include an Influxdb (a time series database) as well as Telegraf. Both play a role in the collecting and sending of database metrics which are then displayed in the UI, a significant differentiator of DSM over other DBaaS offerings. Note also that the menu list in the Provider UI is different for the Org Admin when compared to the Provider Admin menu list. As mentioned, there is no System Logs entry in the Org Admin menu list.
Note that an Org User can also navigate to this area of the UI, and if an Org User requests to generate a log bundle from this location (Environments), they are also prompted to include agent logs as well as any database logs. Again, an Org User will only be able to select databases that it owns. Below is what an Org User will receive when they generate a log bundle from the Environments view, and select the agent logs and the appropriate databases. The log bundle is agent and database specific, and does not include any infrastructure logs.
As you might expect, the Provider Admin can also navigate to this view and generate logs. However, the Provider Admin can capture logs from any database, whether or not it is the owner of the database or not.
Database Logs
Lastly, we come to database logs. Any user can generate database log bundles. In the example below, it is an Org User who is generating the database log bundle. Once again, most of the logs relate to the adapter which implement database tasks that have been requested via the provider UI. If interaction with a database is not behaving correctly, this would be a good log bundle to capture. Again, this user does not have System Logs access and can only select databases that the user is owner of.
Summary
To recap, the following roles in VMware Data Services Manager:
| Role | Log Bundles which can be generated |
| Provider Admin | System Logs, Environment Logs, Database Logs from any database |
| Org Admin | Environment Logs, Database Logs from any database the user owns |
| Org User | Environment Logs, Database Logs from any database the user owns |
Hopefully this post has now shown you which logs to gather for troubleshooting purposes, and which permissions and roles are needed to gather them. The restriction on who has permission to generate the various logs avoids any security missteps and prevents end-users / developers getting access to infrastructure information.
Also note that it is possible to forward logs from the various components to something like VMware’s Aria Operations for Logs, formerly vRealize Log Insight. An earlier blog post details how this can be achieved.
