how can I see the arguments passed to a stored proc on Azure? The query that I'm using: 

SELECT 
    deqs.execution_count,
    deqs.last_execution_time,
    dest.objectid,  
    SUBSTRING(dest.[text], (deqs.statement_start_offset/2)+1,
                        ((CASE deqs.statement_end_offset WHEN -1 THEN DATALENGTH(dest.text)
                              ELSE deqs.statement_end_offset
                            END - deqs.statement_start_offset)/2)+1) AS statementtext 
    , dest.[text]   
FROM sys.dm_exec_query_stats AS deqs 
CROSS APPLY sys.dm_exec_sql_text(deqs.sql_handle) AS dest
where dest.[text] like '%foo%' 
order by deqs.last_execution_time DESC


That gives me 10 hits, but unfortunately I can't see what arguments were passed in. In regular SQL land I'd just attach the profiler, but that's not an option. This answer on SO makes me think it's not possible, which is hard to believe -- seeing proc arguments is an important debugging tool. 

How can I see the last few procs that were run, along with their arguments on Azure?
Today, I think you would have to add logging to the stored procedures (or to the calling application). Trace / profiler are not supported on Azure SQL Database, and never will be.

At some point in the future, you should be able to use database-scoped Extended Event sessions. Bob Beauchemin talked about this here and here, and there is an official marketing statement from Microsoft's Tiffany Wissner here (but nothing technical):


Preview Available for Latest Version of Azure SQL Database


If you have an Azure database and you happen to be on the most recent public version (13.0.15 as far as I can tell), you can start to see some evidence of her statements about Extended Events. For example, I have a context menu item that I can't do anything with yet:



So, it's coming, just not yet. Until then I can't really think of a decent way to obtain runtime parameter values for called procedures unless you change the application to retrieve actual, post-execution plans and log the XML output somewhere. And if you're going to do that, well, you may as well just add the logging of the actual values - much easier to consume.

This answer, of course, is subject to change as it gets older.