To fully qualify a ticket so support can quickly process and understand the issue, it's necessary to gather certain information.
- Clear problem description
If the issue is not reproducible OOTB, please a provide a data package containing sample data that would enable Support to reproduce the issue.
- Confirmation of priority / Business Impact
- Screen shot where applicable
- Contact info and phone number (if not there).
- P1: Request 24/7 Contact Information & phone number
- When did the problem started / when did it work last
- Any changes that were made recently before the issue appeared
- Version and build number being used
- Full OS and DB type and versions used
- Full logs files of the Campaign instance that contains the timeframe where the issue is visible. See the Campaign Log Files doc page.
- All Configuration files: config-<instance>.xml , serverConf.xml, See the Server Configuration doc page.
- What exact component is slow: UI, Workflow, Query, etc.
- What makes you think it’s slow?
- Has the workflow/query been executed before ? Do you have previous runtime to compare them too ?
- TODO: how to pinpoint the step of the workflow causing problem. How to identify which query is slow?
- What does fast look like or what are you comparing it against?
- Internal name of the workflow
- What part or the workflow is not performing (any particular activity?)
- Is it a one-off or systematic occurrence?
- Number of concurrent workflows running at the same time ?
- Is “Keep interim results between population” enabled for this workflow? Usually, during testing and debugging the workflow, users turn on the option to 'Keep the result of interim populations between two executions'. This option is useful when debugging since it allows you to view and analyze the population. However, keeping this on for longer period of time would retain all working tables (it will not get purge by the automatic process) and will degrade system performance : best practices for performance issue
- Is SQL logging enabled? TODO: add how to check (link doc)
- On-premises only: audit logs for the workflow
- Is the connection to console slow or navigation within the console ?
- Provide steps via which we can experience the same.
- Have you tried to clear local (soft) cache?
- Use TraceView to capture trafic between the console and server instances.
- TraceView can be found in the Campaign Server installation folder bin\tools
- It runs on port 6666, therefore ensure no syslogd from a running server instance is running as well.
- Save the calls made when executing the slow actions.
- Internal name of the delivery
- Number of deliveries concerned
- For slow performance: Expected Throughput and Current Throughput?
- On-premises only: audit logs for the delivery. TODO: should we increase the log level to have more infomation
- TODO: messages to be sent (from workflow output), Processed (by MTA) or Success (ISP confirmed deliveries)
The frequent restart due to crashes can be established by specific logs and coredump presence (if enabled).
In most of cases, specific messages appears in the watchdog.log. This can also be correlated by presence or core files (or sent_core files if processed by ZeroCrash) in /usr/local/neolane/nl6/var directory:
In case of server crash most of the time it's a consequences of a soap call. Please try to find which one activating verbose soap logs.
For OnPremise installation we advice to add the following command in the neolane user .bashrc or nl6/env.sh
When reporting crash issue its good to provide the below information which helps us internally to find the cause without causing delays
- Output of ulimit -c
To check it the core dump is complete and usable to investigate , please use the following command on the server where it was generated:
- $ cd /usr/local/neolane/nl6/var
- $ gdb -ex "quit" ../bin/nlserver core.****
If message indicating truncation appears, the core dump are not useful hence you need to ensure core dump truncation restrictions are removed
- Output of uname -a
- $ cd /usr/local/neolane/nl6/var
- $ gdb -ex "bt" --batch ../bin/nlserver core.***
- Copy of email from provisioning team specifying details of provisioning ( If available)
- IMS login to ACC not working for a certain user`s or all
- Any changes done to marketing cloud external account after which it soppted working ?
- What does the error whle logging in says ?
- Web logs to be provided which captures any entry when ims login attempt was made
- Was a build upgrade done post which IMS stopped working ?
- Details of security group and rights listed under your email address in marketing cloud.