One factor which can lead to delays on a Support ticket is a lack of information when a ticket is raised. A lack of information means that Couchbase Support must follow up to request further information, wait for a response, and potentially engage in multiple cycles of back and forth communication before we receive all the necessary information to allow us to investigate an issue or assist further. In some cases, a lack of information on Support tickets can add days/weeks of delays until we receive all the information we require to investigate or assist further.
This is a problem that can be addressed by ensuring that Support requests are raised with as much information as possible. Raising tickets with as much information as possible, and pro-actively uploading logging prevents delays incurred as a result of Couchbase Support needing to request further information. Often, the Support tickets that are raised with the most information are the Support tickets that are resolved the fastest, as these tickets avoid unnecessary delays, and contain all the information needed for a swift investigation to take place, allowing us to identify the cause of an issue and suggest a resolution as soon as possible. Providing as much information as possible will help us fast-track your request, and will allow us to provide the best level of service for your support requests.
- General Issues
- Common Issues
- Timeouts
- Slow Operations
- Slow Queries
- Incorrect Query Results
- Application (Couchbase SDK) Issues
- XDCR Mismatch
- High CPU/Memory
- Mobile Sync Issues
General Issues
For most issues, we will generally require the following details as a minimum, though the specifics will depend on the nature of the issue being raised. Please review these points, and ensure your Support ticket is updated with any missing details which may be relevant to your issue.
| Information Required | Why do we need this? |
|---|---|
| What issue did you observe? | It is crucial that we receive a description of your issue. This helps us begin to development an understanding on which product and component is affected. This also determines how we will approach the issue, and what other information/diagnostics are required for us to proceed. If your Support ticket does not contain a description of the issue, this will delay the progress of your request, as we will need to follow up to request further information to understand your concerns before we are able to proceed with any further steps. |
| When did the issue occur or begin? (Please provide a date/time and confirm the timezone). |
Knowing when an issue occurred/started is crucial to allowing us to investigate the issue. For most issues, this will allow us to verify that any logs collected cover the correct time period and helps us find the log messages that correspond to the issue for further investigation. Knowing the timeframe of an issue also eliminates ambiguity and allows us to direct our log analysis on the relevant time period. Not knowing the timeframe of an issue may make it difficult for us to find evidence of the issue in any relevant logging, which could prolong our investigations or make it impossible for us to find the root cause. |
| What is the Current Impact of your issue? (Ie. How is this issue affecting your end users or project delivery pipeline?) |
Having an accurate description of the impact of your issue helps us understand the context in which the issue has occurred. This helps us determine the approach that we will take in handling your issue. For example, on issues where there is a high impact we may prioritise quick actions to return your deployment to a healthy state as quickly as possible. For issues where there is low/no impact, we may prioritise a comprehensive investigation to ensure the issue is fully understood before taking actions. |
| Were any recent changes made to your deployment/environment? |
For most requests, it can be helpful to understand what changes were recently made to your deployment/environment. This provides us with useful context, and helps us take into account whether any recent actions/events could be related to any issues that you have observed.
|
For most issues we may need to request confirmation of the above items where relevant. If any of the above information is not provided in your initial response that you think may be relevant, please follow up and provide this information in your reply as soon as you are able to do so.
Common Issues
In addition to the points discussed above, we may also need to request further information for specific issues that are commonly reported for certain Couchbase products. If your issue is discussed below, please review the information that we are likely to require to investigate your issue. Pro-actively providing this information as soon as possible will help ensure that we are able to proceed with investigating your issue as soon as possible. If any information or logging is not provided on your Support Ticket, this may introduce delays as we may need to wait for this information before we are able to proceed.
Timeouts
| Information Required | Why do we need this? |
|---|---|
| What type of operations are affected? |
Knowing what type of operations are affected is essential to understanding which component within Couchbase Server should be investigated further. This determines how we will investigate the issue, and which log files we will need to review as part of our investigations. We typically cannot begin investigating until we know which type of operations are affected.
|
| Where are the timeouts seen from? |
We need to know where the timeouts are seen from as this helps us determine which parts of the stack could be introducing latencies. This also helps determine what logging we will need to collect to investigate the issue.
|
| Which Couchbase SDK and version is in use? | If the timeouts are reported from an application that uses a Couchbase SDK, it is important to confirm which SDK is in use as well as the version (eg Java SDK, version 3.8.0). This helps us confirm which product is in use and allows us to take into account whether any known issues specific to the version could be relevant to the issue. The full suite of Couchbase SDKs can be found in our documentation. A list of versions can be found in the Release Notes for each SDK, for example Java SDK Release Notes. |
| When did the timeouts start? | As mentioned under General Issues, it is crucial for us to know when the issue started, as this directly determines which period of time we may need to review in any relevant logging. Without this information, we may be unable to verify that the logs cover the relevant time of the issue. This also helps us understand whether the timeouts are a new issue, or whether these have always been present. |
| What proportion of operations are affected? | Knowing what proportion of operations are affected allows us to understand the scale of the issue. If ~100% of operations are affected, this could signify a critical issue with your deployment meaning a different approach is needed to restore stability to your deployment as soon as possible. By contrast, if ~1% of operations are affected, we may need to take a more thorough and methodical approach to investigate the issue. |
Slow Operations
| Information Required | Why do we need this? |
|---|---|
| What type of operations are affected? |
Knowing what type of operations are affected is essential to understanding which component within Couchbase Server should be investigated further. This determines how we will need to investigate the issue, and which log files we will need to review as part of our investigations. We cannot begin investigating until we know which type of operations are affected.
|
| How long are operations taking? | We need to know how long your operations are taking to understand your concerns. Please ensure this information is specified when raising concerns about slow performance. |
| How long are operations expected to take, and why? | In addition to knowing the extent of the slowness, we need to know how much this deviates from your expectations, and what your expectations are based on. For example, if your queries were previously completing in 50ms, but are now taking 3s, it is reasonable to assume that your queries should continue to complete in 50ms (based on previous performance). This could be indicative of a recent change in your cluster that needs to be investigated further. By contrast if your queries are taking 3s and have always taken 3s, but your requirements mean that your operations must complete in less than 1s, this could indicate that your indexes/queries need further optimisation, rather than being the result of an unexpected issue in your cluster. The extent of the slowness compared to your expectations may also determine the approach we need to investigate the issue. An issue where operations are taking taking 40us (when they were previously taking 10us) will require a different approach to an issue where operations are taking 40s (when they were previously taking 1s). |
| Is this a new issue, or has performance always been slow? | We need to establish if your deployment was previously working as expected, or whether the issue has always been present in your environment. This helps us understand whether the issue could be related to a recent event or change that occurred within your deployment, or whether it is likely to be related to the configuration / environment of your deployment. |
Slow Queries
| Information Required | Why do we need this? |
|---|---|
| Affected query statement(s). | If only certain statements are affected by the slowness we will likely need to collect further information on those specific statements. Please confirm the affected query statement(s) on your Support ticket to allow us to assist further. If all statements are affected, this could suggest wider issues in your deployment that could be more general to the health of your cluster. In this case, please provide us with some example statements of any affected queries so that can review these further. |
| Plan Text for affected query statement(s). |
The Plan Text output contains information on the Plan used for the execution of a query. This provides us with insight into the different phases of execution that were used for the query. This also provides us with timing information and documents counts for each phase of the query, which can help us to identify which phase of query execution caused the slowness. This information is essential to understanding why a specific query was slow.
|
| How long are operations taking? | If operations are taking longer than expected, we need to know how long the operations are taking to understand your concerns. This helps us understand the scale of the issue, and allows us to verify that the issue is captured within any logging or diagnostics that may be collected for investigations. |
| How long are operations expected to take, and why? | In addition to knowing the extent of the slowness, we need to know how much this deviates from your expectations, and what your expectations are based on. For example, if your queries were previously completing in 50ms, but are now taking 3s, it is reasonable to assume that your queries should continue to complete in 50ms (based on previous performance). This could be indicative of a recent change in your cluster that needs to be investigated further. By contrast if your queries are taking 3s and have always taken 3s, but your requirements mean that your operations must complete in less than 1s, this could indicate that your indexes/queries need further optimisation, rather than being the result of an unexpected issue in your cluster. The extent of the slowness compared to your expectations may also determine the approach we need to investigate the issue. An issue where operations are taking taking 40us (when they were previously taking 10us) will require a different approach to an issue where operations are taking 40s (when they were previously taking 1s). |
| Is this a new issue, or has performance always been slow? | We need to establish if your deployment was previously working as expected, or whether the issue has always been present in your environment. This helps us understand whether the issue could be related to a recent event or change that occurred within your deployment, or whether it is likely to be related to the configuration / environment of your deployment. |
Incorrect Query Results
| Information Required | Why do we need this? |
|---|---|
| What behaviour are you seeing? What is the expected behaviour? |
We need to know what unexpected behaviour you are seeing to help us understand your concerns. For example, if you seeing fewer results than expected, more results than expected, or different results than expected. This helps us understand how the behaviour you observed deviates from the behaviour you expected to see. If you are seeing different results than expected, explaining which documents are seen, which documents are expected, and why, greatly helps us understand your concerns. |
| Affected query statement(s). | Understanding the query statement itself will allow us to focus our investigations on the specific behaviour you are concerned about. This will allow us to take further steps to investigate your issue. |
| Affected query result(s). | Providing the results from the affected query demonstrating the issue helps us understand the behaviour you are seeing. It can often be helpful to provide screenshots to accompany your explanations, as this eliminates ambiguity. Sensitive information contained in query results should be removed/redacted as necessary. |
| Plan Text for affected query statement(s). |
The Plan Text output contains information on the Plan used for the execution of a query. This provides us with insight into the different phases of execution that were used for the query. This also provides us with timing information and documents counts for each phase of the query. This can help us pinpoint where any unexpected behaviour occurs during the execution of your query.
|
| Sample documents (correct/incorrect behaviour). | Please provide a sample document of a document that correctly appears in your query result (if applicable) and a document that incorrectly appears (or doesn’t appear) in your query result (depending on the nature of the issue). This is to help us attempt a reproduction of the behaviour to verify whether the behaviour is occurring as a result of an issue within Couchbase Server. Couchbase Technical Support will typically attempt to reproduce the behaviour if appropriate regardless of whether sample documents are provided, however having sample documents which are confirmed to trigger the issue in your environment will help us verify this more quickly, and with greater accuracy. |
| Steps to reproduce. | For the quickest turnaround, please provide steps that can be used to reproduce the issue independently of your environment, if possible. This will help us verify the behaviour as quickly as possible, and will allow us to collect further detailed diagnostics in our own test clusters for further investigation alongside our Development Team. If this information is not provided, we may still attempt a reproduction of the behaviour you have reported, however this may take longer and may have a lower chance of success, which could require us to collect further information to proceed. |
Application (Couchbase SDK) Issues
| Information Required | Why do we need this? |
|---|---|
| Which Couchbase SDK and version is in use? | If any issues are reported regarding an application that uses a Couchbase SDK, it is important to confirm which SDK is in use as well as the version. This helps us confirm which product is in use and allows us to take into account whether any known issues specific to the version could be relevant to the issue. The full suite of Couchbase SDKs can be found in our documentation. A list of versions can be found in the Release Notes for each SDK, for example Java SDK Release Notes. |
| Example log messages or snippets | This helps us understand which errors or exceptions you are concerned about, and helps us verify whether your logging covers the reported issue or not. |
| Application logs (Couchbase SDK logs) | The application logs (containing logging from the Couchbase SDK) provides us with information on the events, errors, and exceptions logged by the Couchbase SDK. This is the main diagnostic item we will use to help us investigate Couchbase SDK related issues. Without this logging, we have no insight or visibility into what behaviour may be occurring within the Couchbase SDK. Application logs should be collected before Couchbase Server logs for your cluster are collected. Since application logs typically cover a shorter period of time compared to Couchbase Server logs, this will help ensure both sets of logs cover the same time period. It is crucial to ensure that both the application logs and Couchbase Server logs cover the same period of time as this allows us to correspond events across both sets of logs. If the application is not currently logging Couchbase SDK messages then please refer to the appropriate Couchbase SDK documentation (please choose the correct version of your SDK) for information on setting up SDK logging, preferably at level INFO/DEBUG, configure a client to log, and collect the logs after the issue in question has occurred. If Couchbase SDK logging is not enabled, we may not be able to proceed until this is configured, and logs are collected covering the issue timeframe. |
XDCR Mismatch
| Information Required | Why do we need this? |
|---|---|
| When did the mismatch begin? | This helps us narrow down the start time of the issue which helps us pinpoint our investigations in the logs. This also eliminates ambiguity and ensures we are focussing on the correct time period that is relevant to your concerns. |
| How many documents are missing or mismatched? | This helps us understand the extent of the issue. For example, is there a document count difference of 1-5 documents between your clusters with XDCR, or is there a document count difference of 100k documents between your clusters? Depending on the volume of data and other factors specific to your deployment, small discrepancies could be expected as part of the normal functioning of XDCR, due to the eventually consistent nature of XDCR. Larger discrepancies could indicate further issues that require investigation. |
| What is the topology of your XDCR replication? |
Please confirm the clusters involved in the affected XDCR replication, and the direction of the replication(s) between them. Having a clear explanation of your topology helps us build a good understanding early on so that we can direct our attentions on the relevant cluster(s).
|
| Affected bucket(s) | XDCR replications are specified to replicate from a source bucket to a target bucket. In addition to knowing the clusters involved, it is important to specify which buckets are involved so that we can focus on the correct replication. |
| xdcrDiffer output. | For some issues relating to XDCR document count mismatches, we may request output from our xdcrDiffer tool . The xdcrDiffer tool connects to two clusters with an XDCR replication between them and compares the data on each cluster. The tool then highlights any inconsistencies that may be a cause for concern. This can be helpful when evaluating document count mismatches, or concerns around replication issues. The tool can be accessed in its GitHub repository, which is located at the following URL: https://github.com/couchbaselabs/xdcrDiffer . The README.md in this repository contains the full instructions required to compile and run this tool. |
High CPU/Memory
| Information Required | Why do we need this? |
|---|---|
| Couchbase Server logs (collected at the time of the issue). | It is important to ensure that your Couchbase Server logs are collected at the time of the issue, if your issue relates to high CPU/Memory. This is because the cbcollect_info tool (used for log collection) runs a series of diagnostic commands and collects profiling which only provides a snapshot of the system at the time of log collection. This means that if the issue is no longer occurring at the time of log collection, the diagnostic information / profiling may not provide insights into the high CPU/Memory usage. |
| What level of CPU/Memory usage are you observing? | This helps us understand your concerns and allows us to verify that any logging covers the issue that you have observed. |
| What is the expected level of CPU/Memory usage, and how was this determined? | This helps us understand the extent of the issue and how much this deviates from your expectations. For example, if CPU usage is typically 30%, and recently spiked to 60%, your expectation of lower utilisation may be based on previous performance. A sudden change in CPU could be indicative of a recent change in your cluster, or an issue that needs to be investigated further. By contrast if CPU usage is 90% and has always been 90%, this may be expected based on the current load and sizing within the cluster. In this case, an expectation for lower CPU utilisation may not be justified, and improved sizing may be required to optimise performance. Knowing your expectations and what these are based on helps us determine the next steps, and allow us to take this into context when investigating further. |
| Is this a new issue, or has CPU/Memory always been high? | We need to establish if your deployment was previously behaving as expected, or whether the issue has always been present in your environment. This helps us understand whether the issue could be related to a recent event or change that occurred within your deployment, or whether it is likely to be related to the configuration / environment of your deployment. |
Mobile Sync Issues
| Information Required | Why do we need this? |
|---|---|
| What synchronisation issue are you observing? |
This helps us understand your concerns. For example, are some documents not syncing as expected, or is there a delay observed for synchronisation between two parts of the stack?
|
| Affected document IDs. | This helps us verify whether the logs cover the issue, and allows us to begin investigating by focussing on specific example documents that are known to be affected by the issue. |
Comments
0 comments
Article is closed for comments.