I've tried porting NLog to Metro-style/WinRT a couple of times, and I've surrendered both times within hours of starting. The problem with NLog is that it's amazing, rich surface area extends all the way over the Metro-style surface area. Whereas in .NET Full you have Console, Debug, and Trace, in .NET Core you only have Debug. Talking cross-process is out. There's no event log support (which is a mistake in my book). The file API is synchronous. Queuing is hard, etc. In short, although NLog will run on anything and is fantastic, it's too big a solution for Metro-style very focused capabilities.
What I see as the total surface area of logging on Metro-style is being able to send information to Debug.WriteLine, and also to dump out crash reports to disk, or maybe HTTP. Don't forget that Debug.WriteLine ends up in OutputDebugString and hence in the regular Windows debug stream. You can use DbgView to surface information outside of the process, which is helpful if your Metro-style process won't start. Likewise, dumping a file to disk on ERROR or FATAL is also helpful - providing you can write it before you're scrubbed out of memory.
To that extent, I've put together MetroLog. This is a first pass over a very basic logging framework that's optimised for Metro-style/WinRT development. It's not intended to become huge like NLog.
I've tried to keep the construction compatible, whilst lightweight. So you still have LogEventInfo, and Logger. It could be that these two libraries converge again in the future, or it could be as @davkean suggested that actually it make sense to restructure the lot around Portable Class Libraries.