# Run filebeat from the command line and add debugging flags to increase verbosity of output
# -e directs output to STDERR instead of syslog
# -c indicates the config file to use
# -d indicates which debugging items you want -- * for all
/opt/filebeat/filebeat -e -c /opt/filebeat/filebeat.yml -d "*"
Tag: debugging
PHP: Dumping Variable to Error Log
It would be great to error_log(var_dump($arraySomething)); but, alas, it doesn’t work like that. I don’t want to bother making a function that does work (ob_start and ob_end_clean should do it) … so I use print_r instead:
error_log(print_r($arraySomething, true));
Boolean Opts in Python
I have a few command line arguments on a Python script that are most readily used if they are boolean. I sometimes need a “verbose” option for script debugging — print a lot of extra stuff to show what’s going on, and I usually want a “dry run” option where the script reads data, performs calculations, and prints results to the screen without making any changes or sending data anywhere (database, email, etc). To use command line arguments as boolean values, I use a function that converts a variety of possible inputs to True/False.
def string2boolean(strInput):
"""
:param strInput: String string to be converted to boolean
:return: Boolean representation of input
"""
if isinstance(strInput, bool):
return strInput
if strInput.lower() in ('yes', 'true', 't', 'y', '1'):
return True
elif strInput.lower() in ('no', 'false', 'f', 'n', '0'):
return False
else:
raise argparse.ArgumentTypeError('Boolean value expected.')
Use “type” when adding the argument to run the input through your function.
parser.add_argument('-r', '--dryrun', action='store', type=string2boolean, dest='boolDryRun', default=False, help="Preview data processing without sending data to DB or Kafka. Valid values: 'true' or 'false'.")
MythTV Verbose Logging
In the process of troubleshooting UPNP/DLNA on our MythTV server, I learned that you can send logging verbosity settings while the server is running. Using the mythbackend binary with the –setverbose flag, you can specify logging level. For example:
mythbackend --setverbose http:debug,upnp:debug
What items can you set levels on? It’ll conveniently tell you — “all” or “none” override existing settings, everything else will update the current logging levels (i.e. if I’ve already got http and upnp in debug, I can use “–setverbose audio:debug” to add audio to the list of things in debug mode).
[mythuser@server /var/log/mythtv/]# mythbackend -v help Verbose debug levels. Accepts any combination (separated by comma) of: all - ALL available debug output audio - Audio related messages channel - Channel related messages chanscan - Channel Scanning messages commflag - Commercial detection related messages database - Display all SQL commands executed decode - MPEG2Fix Decode messages dsmcc - DSMCC carousel related messages dvbcam - DVB CAM debugging messages eit - EIT related messages file - File and AutoExpire related messages frame - MPEG2Fix frame messages general - General info gpu - GPU OpenGL driver messages gpuaudio - GPU Audio Processing messages gpuvideo - GPU video rendering messages gui - GUI related messages http - HTTP Server messages idle - System idle messages jobqueue - JobQueue related messages libav - Enables libav debugging media - Media Manager debugging messages mheg - MHEG debugging messages most - Most debug (nodatabase,notimestamp,noextra) network - Network protocol related messages none - NO debug output osd - On-Screen Display related messages playback - Playback related messages process - MPEG2Fix processing messages record - Recording related messages refcount - Reference Count messages rplxqueue - MPEG2Fix Replex Queue messages schedule - Scheduling related messages siparser - Siparser related messages socket - socket debugging messages system - External executable related messages timestamp - Conditional data driven messages upnp - UPnP debugging messages vbi - VBI related messages xmltv - xmltv output and related messages
To disable debugging, use “mythbackend –setverbose none”
Teams Debugging
The Teams desktop client is an Electron application – which means you can debug the Teams client just like any other Electron application. To set up debugging through Chrome, open Chrome to chrome://inspect Configure network targets. Click “Configure”
Add an unused port to be used for Teams debugging.
Run Teams with the remote debugging flag port set to the same port you added above. E.g.
%userprofile%\AppData\Local\Microsoft\Teams\current\Teams.exe –remote-debugging-port=51555
Now you’ve got access to the Electron app in Chrome. Click on “Inspect” for the thread you want to watch
You can add break-points in the code to pause program execution.
You’ll see a “Paused in debugger” indicator when a breakpoint is reached. You can resume or step over using this indicator, or you can use the DevTools debugger – the DevTools debugger also allows you to proceed one step at a time through program execution (F9).
Through the debugger, I was able to identify the source of the weak little notification ding
https://statics.teams.microsoft.com/hashedassets/audio/Teams_Notification_Secondary-a8621153.mp3
Which means I can redirect this URL … really anything that matches the URL up through Teams_Notification because I expect the alpha-numeric at the end to change and I’m sure there’s a primary notification 😊 … and make the notification noticeable.
Looking through the package, I see eighteen different ‘ringtone’ type MP3 files, and only three lines of code that use them. Hopefully this is an indicator that MS has begun development of some user-selectable notification sounds in the desktop client.
nonMeetupRingAudio = new Audio(data.assetsPath + ‘audio/ring.mp3’);
meetupRingAudio = new Audio(data.assetsPath + ‘audio/meetup_ring.mp3’);
screenshareRingAudio = new Audio(data.assetsPath + ‘audio/screenshare_ring.mp3’);
Accessing MS Teams Log Files
There are two sets of log files that we can use to troubleshoot Microsoft Teams issues.
Debug Logs On Windows, these are accessed by holding CTRL + ALT + SHIFT + 1 … on OSX holding Option + Command + Shift + 1 — both the desktop and web client will download three files. In the web client, you’ve got to tell it to save each file individually. The desktop client automatically stashes the files in your downloads folder (sorry, OSX folks, not a clue where your files are!).
Bootstrap log: Teams desktop also has bootstrap logs at %appdata%\Microsoft\Teams\logs.txt This file is generally useful for launch failures, authentication failures, and issues where the app is restarting. Once Teams is started, only background authentication ‘stuff’ is logged here.
If you’re inclined to read them, the debug client log is JSON formatted text followed by lines with timestamp, message level, and the message. War (Warning), Err (Error), Inf (Informational) messages appear in the log. When my Internet connection goes flaky, I get “War” messages with timeouts. But I’ve also seen really strange errors about the back-end Skype call not being found (AFAIK, Skype and Teams share a back-end calling infrastructure. The Skype back-end was upgraded for the Teams launch, but it’s a shared resource).
I pull the log file into Excel and split it into columns with the timestamp, severity, and log data. You can use
=DATEVALUE(MID(A1,1,10))+TIMEVALUE(MID(A1,12,8))
to convert an ISO8601 timestamp into a value on which Excel can perform calculations. You can also just reformat it by replacing ‘T’ with a space and removing the ‘Z’ 
For some activities, you can isolate the end-to-end transaction. This means you can also calculate how long the transaction took. At-mentions are great because they’ve got an obvious start (search text entered … length 0 means just the @ symbol was used. You’ll see different lengths depending on what the user actually types) and an obvious end (dropdown is shown for X search results). There’s also a single remote call (calling atMentionsService.SearchForUserPrifileInChannel) and response (scope.processSearchResults) where you can determine delay introduced outside the local computer.
When performing calculations in Excel with DateTime objects, the result is in unit days. To display the results in seconds, multiply this by 86400 (number of seconds in a day, which anyone who ever administered Bind zone files will be able to tell you off the top of their head … otherwise 24 * 60 * 60)
In the at-mention above, it took a little over half a second to complete and all of that time was the network call.