exceptions.TypeError: must be encoded string without NULL bytes, not str

Carbon converts the metric name into a filesystem path with just a substitution:
  join(settings.LOCAL_DATA_DIR, metric.replace('.','/')) + '.wsp'

os.path.exists() is complaining of a null byte so there must be a null byte getting sent in one of your metric names

Hi thank you for the advice, it sounds sensible.

I altered my script that sends the metrics, so that it logged them all in a file. I have about 2.5k metrics and I've played with them with grep and excel and so far I can't find any problems with the metrics in the file?

I stopped sending metrics when I created this question (around 2 days ago), but the console.log file is still filling with one exception per second. Could it be stuck trying to do something?

Many thanks

PS I'm off on a 2 week holiday tomorrow, so my apologies if my reply is delayed

I had a look at the code in the exception trace and had a though....would I be taking my life in my hands if I altered the file /opt/graphite/lib/carbon/writer.py, to send the metric to the log file, just before trying to look for its path? This may give me an idea what it's failing to work with.

Would I need to restart something for the code to take affect?

I'm not a real python programmer, but I can understand the basics, I was thinking something along the lines of:

def optimalWriteOrder():
  "Generates metrics with the most cached values first and applies a soft rate limit on new metrics"
  global lastCreateInterval
  global createCount
  metrics = MetricCache.counts()

  t = time.time()
  metrics.sort(key=lambda item: item[1], reverse=True) # by queue size, descending
  log.msg("Sorted %d cache queues in %.6f seconds" % (len(metrics), time.time() - t))

  for metric, queueSize in metrics:
    if state.cacheTooFull and MetricCache.size < CACHE_SIZE_LOW_WATERMARK:
      events.cacheSpaceAvailable()
# ------------------------------------------------
# my new piece of code
#
    log.msg("reviewing metric:"+metric)
# ------------------------------------------------
    dbFilePath = getFilesystemPath(metric)
    dbFileExists = exists(dbFilePath)

Null characters wont show with grep - you may want to try catting the file with cat -e which will display null characters as ^@

The log statement is fine - you may want to add another log message after the dbFileExists statement below it since that's the line it's going to blow up at if there are nulls.

I'm back from my holiday and working on this problem again.

I implemented the above logging which gave me some confusing results. The log message clearly shows some bad characters in the directory name:
¬ítúuk.test.wlst.jvm.AdminServer.usedjvm
The text should start with "uk". However, I had shutdown carbon, restarted it and left it running for a while, then sent some values, but not the value above.

Basically the log files were clean for a few hours, then started getting this error for a metric I hadn't sent.

There was also an error for a metric I had sent, but I'm not sure if that's related:
¬ítQàuk.test.wlst.jdbc.com_bluemartini_dbpool_OneTouch_search.WaitingForConnectionCurrentCount

I also log all the metrics to a test file at the same time as sending to graphite, these bad characters do not exist in the log file.

So I have 2 questions.
1) Is there a file of cached values I need to clear out, before running my tests
2) Is there some way anyone can see how I get these bad characters in the metric names?

Many thanks

I have a solution. To be clear there was no fault with the graphite tools either.

My code to send data to graphite is written in Jython and there were some problems with standard python code so the guy setting it up for me resorted to java and used an ObjectOutputStream to send the data.

It's taken me a while to figure it out, but ObjectOutput stream sends the text as an object, and must add a little binary padding at the start of my metrics, causing all of my problems. I swapped out to using a Java PrintWriter, which is specifically for text and hey presto. My metrics are now clean.

Thanks for the help Michael, you gave me enough to crack it in the end.